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statement  of  Content 


This  publication,  a subset  of  the  Hydra  Reference  Manual,  is  intended  as  a 
general  introduction  to  the  details  of  the  Hydra  operating  system.  The 
chapters  selected  were  tho.se  considered  relevant  to  a general  understanding 
and  appreciation  of  the  capability-based  protection  system  of  Hydra.  The 
material  also,  includes  the  introductory  and  reference  material  on  the 
mechanism  for  the  switching  of  protection  domains,  the  CALL  inechaiusin. 

This  document  includes  the  complete  Table  of  Contents  and  Inde.v  from  tlie 
Hydra  Reference  Manual  as  an  outline  of  the  total  wcrk..  Omitted  are  the 
chapters  on  Paging,  the  Kernel  Multiprogramming  System  (K.MPS).  th<*  G.ST, 
the  Policy  System  Interface,  the  interprocess  conimuni;  ai:on  >yst«  ni  (the 
Port  system),  the  physical  device  I/O  support,  and  most  ol  :h»  apr*^ndices.  A 
section  dealing  with  the  fine  details  of  LN’S  context  tdocK_>  has  also  been 
omitted. 

For  those  who  are  actually  programming  Hydra,  the  Hydra  Programmer’s 
Supplement  is  available,  which  includes  the  material  on  LNS  context  bloclts 
and  nearly  all  of  the  appendices.  The  chapters  on  KMPS,  the  Port  system,  the 
Policy  system  interface  and  device  I/O  are  also  available  as  separate 
documents,  since  most  users  do  not  need  to  interact  with  the  Kernel  at  those 
interfaces. 

The  Reference  Manual  was  publisued  in  parts  in  order  to  most  efficiently 
serve  all  classes  of  users.  Reference  copies  ol  the  complete  manual  have  been 
made  available  locally. 
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L Introduction 


1.1.  About  the  Reference  Manual 

( 

'-^Th.is  document  is  a reference  manual  for  the  Hydra  Kernel.  It  contains 
a minimal  amount  of  tutorial  information.  Readers  who  are  not  familiar 
with  the  ideas  behind  the  capability-based  protection  systems  so  vital  to 
Hydra  are  encouraged  to  read  first  the  Hydra  article  in  the  CACM  [Wu74], 
and  the  collection  of  papers  given  at  the  Fifth  Symposium  on  Operating 
Systems  Principles,  particularly  the  paper  by  Cohen  [Coh75].  / 

We  want  to  emphasize  that  Hydra  is  not  by  itself  an  operating  system 
in  the  usual  sense  of  the  word:  it  does  not  perform  the  tasks  of  allocation, 
scheduling,  accounting,  and  handholding  that  are  typical  of  conventional 
operating  systems.  It  is  better  to  think  of  Hydra  as  an  e.vtension  of  the  PDP- 
1 1 hardware,  one  which  extends  the  instruction  set  of  the  underlying 
computer.  Hydra  and  the  host  PDP-1 1 together  form  a virtual  machine,  and 
Hydra  is  the  kernel  of  an  operating  system  to  run  on  that  virtual  machine. 
In  fact,  many  different,  competing  "operating  systems"  can  be  running  on 
Hydra  simultaneously.' There  is  a default  user  environment,  consisting  of 
the  Hydra  kernel  and  a collection  of  subsystems,  that  a user  initicilly  faces 
when  he  logs  on  to  Hydra. 

.'Hydra  is  thus  a software  virtual  machine  implemented  on  C.mmp,  a 
closely-coupled  PDP-11 -based  multiprocessor.  The  extended  virtual 
machine  instructions,  i.e.  tho.se  not  provided  by  the  underlying  hardware 
but  by  Hydra,  are  called  K-calls,  or  Kernel  calls.  ^Although  these  K-calls  are 
technically  machine  instructions  for  the  virtualTIydra  machine,  they  were 
implemented  with  the  understanding  that  their  major  use  would  be  in  BLISS 
programs,  and  they  are  all  defined  as  macros  for  the  BLISS- 11  compiler. 
BLISS-1 1 runs  on  the  PDP-10,  and  there  is  a file  (KERKAL.REQ[N8 1 1KYS7]) 
that  contains  ail  these  macro  definitions,  and  which  may  be  included  in  any 
BLISS- 11  compilation.  Appendix  K of  this  reference  manual  is  a 
listing  of  these  K-call  macros. 

This  manual  does  not  contain  any  information  about  the  user 
environment.  There  are  separate  documents  describing  the  various 
subsystems  that  form  the  the  user  environment.  In  particular,  the  reader  is 
referred  to  the  Command  Interpreter  Reference  Manual,  the  Directory 
Subsystem  IWanual,  the  Policy  Module  Manual,  and  various  pieces  of  user 
documentation.  There  is  a document  still  in  preparation  that  will  describe 
the  utility  functions  available  in  the  user  environment. 
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1.1.1  Tlie  Hydra  user  disk  area 

Since  most  of  the  development  of  software  for  Hydra  has  taken  place 
on  the  PDF- 10,  nearly  all  of  the  files  of  interest  to  users  exist  there.  The 
most  important  disk  area  is  [N8 1 1HY97],  on  which  all  of  the  BLISS  require 
files  residf*.  Also  on  this  area  can  be  found  documentation,  the  system  news, 
various  utility  packages,  and  many  other  useful  files.  Most  of  these  are 
described  in  the  companion  volume  to  this.  The  Hydra  Songbook  [Reid75], 
The  Songbook  contains  a user-level  introduction  suited  to  the  user  sitting  at 
a terminal  and  attempting  to  interact  with  the  system.  It  describes  the 
command  interpreter,  interactive  debugger,  and  utility  programs  which 
exist  on  Hydra.  This  document  is  primarily  for  use  by  those  users  writing 
programs  (particularly  BLISS  code)  and  for  those  needing  detailed 
information  during  debugging. 


1.1.2  A Note  on  Notation 

In  this  manual,  fully  capitalized  words  generally  denote  kernel 
operations  (K-calls)  or  object  types.  A special  font  identifies  other  Hydra 
technical  terms,  e.g.  type.  Underlining  indicates  the  defining  occurrences 
of  a non-Hydra  technical  term,  or  otherwise  suggests  importance.  Initially 
capitalized  words  occasionally  identify  uses  of  technical  terms  in  contexts 
where  italics  would  be  confusing  or  overwhelming  in  number. 

Numbers  will  always  be  written  in  decimal,  unless  preceded  by  a hash 
mark  (sharp  sign,  pound  sign),  i.e.,  #10  = 8. 


1.1.3  A note  on  the  revised  edition 

The  Revised  Edition  represents  a major  change  in  the  naming 
conventions  used  in  previous  versions.  The  proliferation  of  symbols  had 
reached  the  point  where  users  could  not  determine  which  symbol  should  be 
used  for  what  purpose,  and  in  many  cases  the  symbols  conflicted  tvith  user- 
defined  symbols.  The  resultant  difficulty  in  creating  programs  indicated 
that  a drastic  change  was  necessary.  Therefore,  the  current  manual  has 
renamed  every  symbol  in  the  Hydra  interface  code,  albeit  often  in  trivial 
ways.  Every  symbol  brought  in  by  a BLISS  "require"  file  now  begins  with  a 
"$"  character.  Furthermore,  some  of  the  naming  conventions  have  been 
made  more  consistent.  In  response  to  user  suggestions  some  of  the  names 
have  been  made  more  mnemonic  or  easier  to  remember,  e.g.,  the  old  symbol 
UCNFRTS  has  been  redefined  to  be  SUNCFRTS  because  most  users 
remembered  that  spelling  rather  than  the  former.  Since  the  symbols  used  in 
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the  old  reference  manual  were  generated  over  a long  period  of  time  and  by  a 
number  of  people,  the  conventions  and  abbreviations  used  tended  to  be 
inconsistent.  In  the  revised  edition,  a concerted  attempt  has  been  made  to 
retain  all  vowels  and  consonants  in  symbols  wherever  this  did  not  result  in 
absurdly  long  symbols.  In  such  cases,  the  abbreviations  were  standardized. 
Many  new  "require"  files  have  been  defined  for  obtaining  useful  s3rmbols, 
and  all  of  these  have  been  documented  as  thoroughly  as  is  feasible.  The 
intent  is  that  all  of  these  changes,  made  when  the  system  is  still  largely 
uncommitted,  will  make  future  use  much  more  comfortable. 


1.1.4  A note  on  the  flags 

Several  sections  of  this  manual  are  flagged  with  special  symbols  in  the 
margin.  These  symbols  represent  the  status  of  Kydra  on  the  date  this  manual 
was  compiled. 

> i\n  asterisk  in  the  margin  indicates  that  the  feature  described  in  the 
text  was  not  implemented  at  the  time  this  manual  was  compiled.  If 
the  feature  is  needed,  you  should  check  the  Hydra  news  files  or  ask 
someone  in  the  Hydra  group  to  determine  if  it  has  been  implemented. 

> The  vertical  bar  symbol  indicates  a change  from  a previous  version 
of  the  manual.  Since  the  changes  from  the  February  14,  1375 
edition  are  so  extensive  it  was  impractical  to  flag  all  of  them,  but 
editions  of  the  manual  produced  after  November  1376  will  have 
such  sections  flagged. 

> A question  mark  indicates  a feature  of  the  system  which  was 
undergoing  redesign  at  the  time  the  manual  was  compiled  and  is 
likely  to  change.  This  flcig  warns  you  that  you  should  check  the 
Kydra  news  for  the  current  specifications. 

> An  "X"  indicates  the  feature  is  obsole:.  ' ut  is  maintained  in  the 
documentation  to  help  people  read  e.’cisting  code,  and  to  encourage 
people  to  recode  programs  that  use  the  obsolete  features.  Users  are 
strongly  discouraged  from  using  obsolete  features,  since  there  is  no 
maintenance  commitment  to  these  features  and  future  compatibility 
is  not  guaranteed. 


1.1.5  The  Hydra  Data  Base 

All  of  the  symbols  defined  in  this  manual  and  their  definitions  are  kept 
in  a large  data  base  file.  This  fils  and  a set  of  associated  processing  programs 
are  used  to  create  all  of  the  user  "require  files"  used  hy  BLISS/ 1 1 users.  It  is 
recommended  that  designers  of  other  systems  use  this  data  base  facility  to 
obtain  definition  files  for  their  programs,  systems,  or  users.  In  this  way, 
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they  can  be  guaranteed  that  their  files  will  always  be  current  with  the 
latest  changes  in  the  system  and  not  made  obsolete  by  upward-compatible 
extensions  or  rendered  inoperable  by  possible  non-compatible  changes. 
Although  the  Hydra  group  recognizes  a responsibility  to  make  as  few  non- 
compatible  changes  as  possible,  Hydra  must  be  considered  a research  system 
and  compatibility  may  conflict  with  other  goals. 

Large  sections  of  this  manual,  particularly  in  the  appendices,  have 
their  contents  generated  entirely  from  this  data  base.  Thus  it  will  be  the 
case  that  as  extensions  are  added  the  manual  will  be  able  to  reflect  these 
with  a minimum  amount  of  effort. 


1.1.6  Aclcnowledgemeiits 

As  in  all  large  systems,  a great  many  people  have  participated  in  the 
development  of  Hydra.  In  addition  to  the  primary  contributors  to  this 
document,  we  must  aclcnowledge  the  contribution  of  all  those  users  who 
helped  debug  this  manual  and  who  provided  the  first  user  community  for 
Hydra.  The  list  of  users  includes,  but  is  not  limited  to,  George  Robertson, 
Richard  Suslick,  Guy  Aimes,  Rick  Gumpertz,  Philip  Karlton,  Peter  Oleinick, 
David  Lamb  and  Brian  Reid. 

In  addition  to  the  original  implementors  of  Hydra,  a number  of  people 
have  contributed  code  to  the  Hydra  Kernel.  This  list  includes,  but  again  is 
not  limited  to,  Sam  Harbison,  Joe  Newcomer  and  George  Robertson.  The 
awesome  task  of  maintaining  the  Kernel  is  currently  the  responsibility  of 
Hank  Mashburn. 

As  an  aside,  Brian  Reid  produced  a special  version  of  PUB  that  could 
cope  with  the  enormous  strain  placed  on  it  by  the  inordinate  amount  of  PUB 
haciting  that  was  used  to  produce  this  document. 

As  in  all  cases  of  acltnowledgements,  there  may  have  been  omissions. 
The  editor  wishes  to  take  this  space  to  apologize  to  anyone  whose  name  has 
been  inadvertently  omitted  from  the  above  list. 
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2.  The  Hydra  Kernel 


2.1.  The  Basic  Kernel 


2.1.1  A Capability  System 

The  Hydra  Kernel  provides  an  execution  environment  in  which 
protection  plays  a key  part.  In  some  systems,  files  are  the  units  of 
protection,  in  others,  segments.  In  Hydra,  the  basis  of  protection  is  an  entity 
called  an  object. 

Many  traditional  operating  systems  are  'access  control  systems';  that  is, 
protection  information  is  associated  with  the  object  being  protected.  For 
example,  in  the  PDF- 10  TOPS- 10  Operating  System,  when  an  executing 
procedure  tries  to  open  a file  (using  an  ASCII  encoding  of  the  file  name),  the 
access  key  associated  with  the  file  is  checked. 

Hydra,  on  the  other  hand,  is  a capability  system.  As  we  noted,  the  basis 
of  protection  in  Hydra  is  an  entity  called  an  object,  and  the  protection 
system  is  invoked  to  determine  whether  particular  accesses  to  objects  will 
be  allowed.  In  a capability  system  an  executing  procedure  has  associated 
with  it  a C-list,  a list  of  capabilities-,  each  capability  contains  the  name  of  an 
object  and  a set  of  rights  which  determine  how  that  object  may  be  accessed 
by  the  executing  procedure. 

Each  different  object  is  assigned  a unique  name  by  the  Kernel.  These 
names  are  guaranteed  unique  for  the  entire  existence  of  the  system  (or 
36,000  years,  should  it  live  so  long).  Rather  than  showing  'real'  unique 
names  in  diagrams,  (represented  internally  by  64-bit  strings),  we  will 
instead  substitute  unique  alphanumeric  names  for  pictorial  clarity.  In  the 
actual  Kernel,  alphanumeric  print  names  are  only  associated  with  classes  of 
objects,  called  types.  Users  are  cautioned,  however,  that  the  Kernel  makes 
no  attempt  to  guarantee  uniqueness  of  these  print  names,  and  in  fact  there  is 
nothing  to  prevent  users  from  creating  new  object  types  (equivalence 
classes)  with  non-unique  print  names. 

As  indicated  above.  Hydra  objects  are  typed.  Examples  of  types  built 
into  Hydra  (called  Kernel  types)  are  PAGZs,  DElTCEs  and  PROCESSes.  There 
is  also  a facility  to  allow  the  creation  of  new  user  types.  Certain  tj^jes 
represent  physical  resources  (e.g.  objects  of  type  DEVICE  represent  actual 
devices;  one  may  represent  a disk,  another  a line  printer,  etc.),  but  in 
general,  types  represent  abstractions  of  resources,  both  physical  and  virtual, 
and  objects  of  such  a type  have  meaning  only  in  terms  of  their 
representation  and  how  that  representation  is  accessed  and  manipulated. 
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Hydra  is  a paged  system.  When  a procedure  executes,  its  code  and 
directly  accessible  data  are  contained  in  pages  represented  by  PAGE  objects. 
Capabilities  for  these  PAGE  objects  must  appear  in  the  C-list  of  the  executing 
procedure.  Section  4 describes  how  to  indicate  to  the  Kernel 
which  of  these  should  be  made  directly  addressable. 

In  Hydra,  an  executing  procedure  is  a distinct  type  of  object,  called  an 
LNS  (Local  Name  Space)  ^ and  differs  from  the  type  representing  its  static 
counterpart,  a PROCEDURE.  PROCESS  objects  are  the  scheduling  entities 
provided  by  the  Kernel.  At  any  instant,  each  executing  process  has  an  LNS 
associated  with  it  which  determines  the  environment  in  which  the  process 
runs.  Hydra  provides  a call  mechanism  which  changes  environments  by 
associating  a different  LNS  -with  a process. 


2.1.2  Objects,  Capabilities,  <m.d  Paths 

Every  object  has  two  parts,  a C-list  containing  a list  of  capabilities,  and 
a data- part  containing  arbitrary  data  represented  as  a vector  of  16 -bit  words. 
The  C-list  and  data-part  of  an  object  together  comprise  its  representation. 

Both  the  C-list  and  data-part  are  linearly  ordered,  based  at  1.  The 
maximum  number  of  capabilities  in  a C-list  and  the  maximum  length  of  a 
data-part  vary  from  type  to  type.  Section  A.4  contains  those 
numbers  for  Kernel  types.  Since  C-lists  are  linearly  ordered,  we  will  often 
refer  to  a capability  as  being  in  the  k'th  slot  of  a C-list. 

As  examples,  let  us  consider  the  representation  of  some  Kernel  objects. 
A PAGE  object  contains  an  empty  C-list  and  its  data-part  contains  the  location 
of  the  page  (disk,  drum,  or  core  address)  and  its  status.  This  data-part  is 
protected  against  examination  or  alteration  by  the  user  program.  The  data- 
part  of  a DEVICE  object  contains  some  information  identifying  the  device. 
The  data-part  of  an  LNS  contains  (among  other  things)  trap  addresses,  a mask 
of  processors  on  which  the  LNS  may  execute,  and  paging  information,  while 
the  C-list  of  the  LNS  contains  the  capabilities  which  define  the  environment 
provided  by  the  LNS. 


There  are  facilities  for  creating  new  types  of  objects  as  well  as  for 
creating  objects  of  existing  types  and  erasing  them.  For  example,  a user 
might  create  a new  type  of  object,  a FILE,  whose  C-list  might  contain 
capabilities  for  PAGEs  and  whose  data-part  might  contain  information  about 
the  file  (it  could  even  be  used  to  hold  access  keys  as  part  of  a system  that 
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could  provide  file  access  checking  in  a vjzy  similar  to  that  of  the  PEP- 1 0 
TOPS  monitor).  Alternately,  a user  might  create  a DIRECTORY  type.  Objects 
of  type  DIRECTORY  might  have  a C-list  containing  capabilities  for  FILES  and 
other  DIRECTORYs.  This  could  be  used  to  build  up  an  hierarchical  FILE 
system  similar  to  the  one  in  MULTICS  ([0rg72]). 

C-lists  and  data-parts  can  only  be  accessed  and  manipulated  through 
j the  Kernel  via  K-calls.  Among  the  many  operations  provided  by  the  Kernel 

I are  some  very  basic  K-calls  that  provide  generic  operations  on  all  types  of 

capabilities.  Typical  operations  allow  a user  to  delete  capabilities  from  the 
C-list  of  some  object,  move  a capability  from  the  C-list  of  one  object  to  the 
C-list  of  another  object  (perhaps  the  same)  with  or  without  deleting  the 
first  capability,  and  move  data  between  the  data-part  of  some  object  and 
directly  addressable  memory.  Of  course,  we  again  stress  that  these 
operations  cannot  be  performed  on  arbitrary  objects;  rather,  the  executing 
LNS  must  have  a capability  for  the  object  to  be  accessed.  In  addition,  as  will 
be  e.xplained  in  the  following  sections,  there  may  be  additional  restrictions 
on  the  operations. 

Most  K-calls  require  some  arguments  which  specify  capabilities.  In 
the  simplest  case,  these  are  denoted  by  simple  indices  into  the  C-list  of  the 
LKS.  For  example,  there  is  a K-call,  $DELETE,  and  SDELETE  ( 3 ) calls  the 
Kernel  to  eliminate  the  3rd  capability  in  the  LNS  executing  that  K-call.  Of 
course,  most  programs  should  use  symbolic  names  or  other  mnemonic  means 
to  create  meaningful  descriptors  for  slot  indices.  We  use  absolute  numbers 
here  to  illustrate  the  simplest  possible  form  in  a K-call. 

Often,  the  Kernel  will  allow  a capability  to  be  denoted  by  a path  index 
(see  Figure  1).  For  example,  SDELETE  ( SPATH(3, 4,2,1)  ) will  delete  the  1st 
capability  in  the  object  referenced  by  the  2nd  capability  in  the  the  object 
referenced  by  the  4th  capability  in  the  object  referenced  by  the  3rd 
capability  in  the  executing  LMS.  The  capability  deleted  is  called  the  target  of 
$PATH(3,4,2,1).  The  capability  denoted  by  $PATH(3,4,2)  is  called  the 
f pretarget  and  the  capabilities  denoted  by  S?ATK(3,4)  and  3 are  called  steps. 

I (Note:  the  denotation  $PATH(3)  is  the  same  as  just  3;  such  paths  are  called 

I simple  paths.) 
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Figure  1 ; Steps,  Pretarget  and  target  in  path  walk 


2.1.3  Generic  Rights  and  Rights  Restriction 

As  we  noted,  Hydra  implements  basic  protection  through  a set  of 
rights.  The  right  to  perform  some  class  of  accesses  (via  K-calls)  with  respect 
to  a capability  is  determined  by  the  presence  of  a particular  bit  in  the  rights 
field  of  a capability^.  The  following  is  a description  of  the  rights  relevant  to 
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basic  Kernel  K-calls.  In  describing  these  rights,  we  consider  the  effect  of 
capability  CAF  having  the  right  in  question.  If  CAP  is  an  object  reference, 
we  write  OBJ  as  a shorthand  for  the  object  referenced  by  CAP. 

Capability  Rights 

$DELETERTS-  Allows  CAP  to  be  deleted  from  the  C-list  which 
contains  it;  i.e.,  permits  the  $DELETE  or  SVACATE 
operation  on  CAP. 

SEMVRTS  - Allows  CAP  to  be  stored  in  some  object;  i.e.,  it  may 
leave  the  environment. 

C-list  Rights 

SGETCAPARTS^-Allows  a capability  to  be  extracted  from  OBJ's  C- 
list;  e.g.,  permits  the  SGETCAPA*^  operation  on  OBJ  Note 
also  that  this  right  is  always  required  on  all  steps  of  a 
path. 

SPUTCAPARTS^-Allows  a capability  to  be  stored  into  OBJ's  C-list; 
e.g.,  permits  the  SPUTCAPA®  operation  on  OBJ. 

SAPPENDCAP ARTS -Allows  a capability  to  be  appended  onto  OBJ's  C- 
list;  permits  the  SAPPENDCAPA  operation. 

$KILLRTS  - Allows  a capability  to  be  deleted  from  OBJ's  C-list; 

permits  the  SDELETE  or  SVACATE  operations  on  OBJ  (as 
opposed  to  SDELETERTS  which  permits  the  operation  on 
CAP). 


There  are  IS  Generic  Rights;  thus  the  generic  rights  can  be  represented  in  a PDP-11  word. 
Only  the  more  interesting  rights  are  doscrl'jed  here.  For  a listing  of  all  rights  and  their 
respective  bits,  see  section  A.l. 

Also  knov/n,  for  historical  reasons,  as  $I,0ADH7S. 


Likewise,  also  known  as  SLOAD. 


Likewise,  also  known  as  3ST0RDRTS. 


Likewise,  also  known  as  SSTORE. 
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Data-part  Rights 

SGETDATABTS-Allows  data  to  be  extracted  from  OBJ's  data-part; 
permits  the  SGETDATA  operation  on  OBJ. 

SPUTDATARTS-Allows  data  to  put  into  OBJ's  data-part;  permits  the 
$PUTDATA  operation  on  OBJ. 

$APPENDDATARTb-*^iows  data  to  be  appended  onto  OBJ's  data-part; 
permits  the  SAPPENDDATA  operation  on  OBJ. 

Restriction  Rights 

$MODIFYRTS- Allows  modification  of  either  OBJ's  C-list  or  data- 
part. 

SUNCFRTS  - Allows  OBJ  to  be  'UNConFined',  that  is,  an  object 
accessed  through  OBJ  may  be  modified. 


2.1.3,!  Some  Examples 


> $DELETE ( 3 ) 

(The  capability  denoted  by  LNS  slot)  3 requires  SDELETERTS 

> $DELETE  ( $PATH(3,4) ) 

3 requires  SKILLRTS  and  SMODIFYRTS, 

$PATH(3,4)  requires  SDELETERTS 

> SDELETE  ( $PATH(3, 4,2,1) ) 

3 and  $PATH(3,4)  require  SGETCAPABTS  and  $UNCFRTS, 
$PATH(3,4,2)  requires  SKILLRTS  and  SMODIFYRTS, 
$PATH(3,4,2,1)  requires  SDELETERTS 


$GETCAPA(x,y)  is  a K-call  which  moves  the  capability  at  y to  x, 
retaining  the  capability  at  y.  x must  be  a simple  index. 


> $GETCAPA(  5,  $PATH(3,4,2)  ) 

3 requires  SGETCAPARTS 
$PATH(3,4)  requires  SGETCAPARTS 
5 must  be  an  empty  slot 
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Note  that  when  a capability  is  moved,  it  picics  up  SBELETERTS,  while 
the  other  rights  remain  the  same  as  in  the  original. 

> $TAKE(x,y) 

like  $GETCAPA  but  also  deletes  the  capability  at  y. 

> STAIvE  ( 5,  $PATH(3,4,3)  ) 

3 requires  SGETCAPARTS  and  SUNCFRTS 

$PATH(3,4)  requires  SGETCAPARTS,  SMODITYRTS,  and  SKILLR7S 
$PATH(3,4,3)  requires  SDELETERTS 
5 must  be  an  empty  slot 


There  is  often  a desire  to  restrict  the  rights  of  a capability  when  it  is 
copied  from  one's  own.  LNS  to  the  C-list  of  another  object.  Hence,  the  K-call, 
$PUTCAPA(x,y,a)  moves  the  capability  at  y to  x (y  must  be  a simple  index), 
and  then  restricts  the  rights  of  the  capability  at  x according  to  the  contents 
of  a mask  at  address  a (see  section  A.2  for  the  format),  by 
eliminating  those  rights  not  represented  by  a 1 in  the  mask.  Note  that  it  is 
always  permissible  to  restrict  the  rights  of  a capability  that  one  possesses. 


> SPUTCAPA  ( $PATH(3,4,3),  2,  addr  ) 

3 requires  SGETCAPARTS  and  SUNCFRTS 
$PATK(3,4)  requires  SPUTCAPARTS  and  SMODIFYRTS 
SPATK(3,4,3)  must  be  an  empty  slot 
2 requires  SENVRTS 


This  call  puts  a copy  of  the  capability  in  slot  2 in  the  destination 
specified  by  $PATH(3,4,3).  The  rights  are  then  restricted  by  the  contents  of 
the  two  memory  locations  specified  by  'addr'  (the  format  of  this  is  irrelevant 
at  the  moment,  but  readers  with  insatiable  curiosity  may  find  it  in  section 
A.2).  It  is  possible  to  restrict  rights  without  moving  a capability  by 
storing  it  into  its  own  slot^. 

I 

If  the  address  designating  the  rights  restriction  mask  is  zero,  no  rights 
are  restricted. 


This  lat’.ar  case  Is  the  only  case  In  which  the  result  of  a SP'JTCAPA  can  be  placed  In  a non 
empty  slot.  Users  are  encouraged  to  use  the  SRaSTRlCTlOM  K-call  to  perform  this  operation. 

t 
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2.1.4  Auxiliary  Rights 

The  rights  we  have  seen  so  far  are  called  Generic  rights  because  they 
have  meaning  for  any  capability  regardless  of  the  type  of  the  object  it 
references.  The  interpretation  of  these  rights  is  performed  by  the  Kernel.  In 
addition,  each  capability  also  contains  a field  of  auxiliary  rights  that  may  be 
defined  differently  for  each  type  of  object®.  Their  use  will  become  apparent 
in  future  examples.  The  assignment  and  interpretation  of  these  auxiliary 
rights  is  left  to  the  discretion  of  the  subsystem  designer;  the  Kernel 
performs  no  interpretation  on  the  au.xiliary  rights  fields  of  user-defined 
objects. 

Note  that  although  the  Kernel  does  not  interpret  these  fields,  in  the 
sense  that  it  restricts  the  operations  which  may  be  performed  on  an  object,  it 
does  perform  the  standard  rights-checlung  which  is  performed  when 
entering  a new  environment,  and  allows  such  operations  as  rights 
amplification-,  these  concepts  are  explained  in  section  2.2. 


2.1.5  Kernel-defined  objects 

The  Kernel  recognizes  a basic  set  of  types  and  treats  them  separatel3^ 
Their  auxiliary  rights  have  predefined  meanings  and  the  Kernel  also  limits 
the  Generic  rights  that  any  capability  for  an  object  of  one  of  these  types  may 
have. 


2.1.6  Empty  slots 

When  a slot  in  a C-list  is  created,  unless  it  is  created  by  storing  a 
capability  into  it,  it  is  said  to  be  uninitialized.  V/ith  a few  exceptions,  any 
attempt  to  access  the  contents  of  an  unitialized  slot  in  a C-list  will  cause  an 
error.  An  uninitialized  slot  is  one  form  of  an  empty  slot. 


Objects  of  type  NULL  represent  absolutely  nothing. 


hey 
9 


constrained  by  the  Kernel  to  have  neither  a C-list  nor  a data-part 


are 

An 


® There  are  eight  auxiliary  rights  bits,  which  are  stored  in  a single  byte,  for  the  exact  format, 
see  section  A. 2. 

3 In  fact,  an  object  of  type  NULL  never  exists^  only  templates  of  type  NULL  can  exist. 
Templates  are  not  discussed  until  section  2,2.2.  But  v/e  digress. 
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■aniiLitialized  slot  contains  a special  kind  of  reference  to  som.eth.ing  of  type 
NULL^*^.  A capability  of  any  type  may  be  stored  in  an  uninitialized  slot. 
Formally,  we  will  say  that  an  uninitialized  slot  is  unbound,  in  the  same  way 
many  programming  language  systems^  ^ mean  that  a value  is  unbound. 


A slot  in  a C-list  is  also  empty  if  it  contains  a reference  to  a NULL 
object ^2.  In  this  case,  the  slot  is  said  to  be  both  defined  and  empty.  The 
capability  in  such  a slot  may  be  operated  upon  as  any  other  capability.  In 
addition,  the  slot  may  be  a target  for  any  sort  of  store  operation;  a NULL 
capability  may  be  replaced  by  any  other  capability. 

If  a slot  in  a C-list  contains  a non-NULL  capability,  it  is  said  to  be 
defined  and  nonempty.  In  most  cases,  an  attempt  to  store  a new  capability 
into  such  a slot  will  cause  an  error. 

A slot  may  be  made  empty  by  either  the  SDELZTE  or  ^VACATE  K-calls. 
The  SVACATE  K-call  deletes  the  capability  at  its  target,  leaving  the  target 
empty  and  defined.  SDELETE  deletes  the  capability  at  its  target,  leaving  the 
target  empty  and  unbound. 


2.1.7  Empty  slots  and  the  C-list  length 

All  C-lists  have  a length  attribute.  The  length  of  a C-list  is  the  index 
of  the  highest  defined  slot  in  the  C-list.  If  a slot  at  the  end  of  the  C-list  is 
made  empty  and  unbound,  the  C-list  size  is  reduced  until  it  again  reflects  the 
index  of  the  highest  defined  slot  in  the  C-list;  it  will  be  at  least  one  less  than 
the  size  of  the  C-list  before  the  last  slot  was  unbound.  Note  that  if  the  slot  is 
simply  made  empty,  but  not  unbound,  no  change  in  the  C-list  size  will 
occur. 

A C-list  is  extended  implicitly  as  a side  effect  of  operations  which 
define  the  contents  of  a slot  in  the  C-list.  In  general,  any  operation  which 
causes  a slot  to  be  defined  will  cause  the  C-list  size  to  be  increased  if  the 
reference  is  to  a slot  outside  the  current  C-list  size. 

In  general,  any  attempt  to  access  an  unbound  slot  in  a C-list  will  result 
in  an  error.  Any  attempt  to  access  a slot  in  the  C-list  beyond  the  current  C- 


A NULL  template  with  SUNBOUNDFLAG  turned  Oi^. 

1 ^ E.g.,  LIS?,  A?L,  WATFOn,  WA7FIV, 

Actually,  a NULL  template  with  SUNECUNDFLAG  turned  off. 
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list  size  but  less  than  the  physical  maximum  permitted  to  that  C-list  will  be 
treated  as  an  attempt  to  access  an  unbound  slot;  if  the  user  is  concerned  about 
the  exact  cause  of  the  error,  a check  can  then  be  made  of  the  C-list  size. 

Each  C-list  has  a maximum  physical  size,  either  an  implementation 
upper  bound  determined  by  the  Kernel  or  a specific  upper  bound  < the 
Kernel  limit  as  determined  when  an  object  is  created  Any  attempt  to 
access  a slot  beyond  the  physical  limit  of  the  C-list  will  cause  a "C-list  bound 
exceeded"  error. 


2.1.8  Types  DATA  and  UNIVERSAL 

It  is  often  convenient  to  be  able  to  create  a new  object  which  simply 
encapsulates  some  data.  The  Kernel  provides  a K-call,  $MAKLDATA,  which 
does  the  encapsulation,  creating  a new  object  of  type  DATA  whose  data-part 
contains  the  data.  DATA  objects  have  no  C-list  and  have  no  defined  auxiliary 
rights. 

The  Kernel  also  provides  a UNIVERSAL  object,  one  with  both  a C-list 
and  a data-part.  The  K-call  SMAICEUNIITIRSAL  creates  just  such  an  object. 


2.1.9  K-call  Values  and  Signals 

Any  K-call  that  executes  successfully  returns  a non-negative  value  in 
BLISS  register  VREG  (assembly  language  RO).  K-calls  that  fail  (e.g.  for 
inadequate  rights)  return  a negative  value,  called  a signal.  In  addition, 
certain  additional  signal  related  information  is  sometimes  placed  in 
$SIGDATA,  a fixed  location  in  the  stack  page^“^.  There  is  also  a mechanism 
that  can  force  signals  to  cause  user  traps  (see  section  2.3.1  for  more 
details).  The  meaning  of  the  various  signals  that  can  occur  during  basic 
Kernel  K-calls  can  be  found  in  section  It  should  be  noted 

that  the  Kernel  signal  mechanism  is  distinct  from  (and  incompatible  with)  a 
similarly-named  facility  in  BLISS- 1 1 . 


f 

K 
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This  Is  a slmpUfled  explanation;  for  more  detail  see  section  2.2.5. 

The  fixed  stack  page  locations  are  described  by  the  file  STKPAG.REQ[.N81 HY97]  and  In 
section  F.5, 


The  Symbols  for  the  Kernel  Signals  are  defined  In  file  SiGNLS.HEQ[N8n HY97].  See  also 
appendix  F. 
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2.1.10  Loclciag  of  Objects 

Since  it  is  possible  for  two  separate  LNS's  to  contain  capabilities  for  the 
same  object,  it  is  possible  that  both  will  be  executing  simultaneously  (on 
different  processors).  Consider,  as  an  example,  the  case  where  a 
programming  error  results  in  both  LNS's  trying  to  SPUTCAPA  different 
capabilities  in  the  same  C-list  slot  of  the  shared  object.  Such  operations  are 
performed  inditrisibly,  when  a capability  or  data  is  being  moved  either  to  or 
from  an  object,  that  object  will  (in  general)  be  locked.  Kence,  in  the 
example  above,  one  LNS  (nondeterministically)  will  gain  access  to  the  object 
and  SPUTCAPA  a capability  in  it,  while  the  other  waits  for  the  object  to  be 
unlocked.  'When  the  SPUTCAPA  K-call  completes,  the  other  LNS  will  gain 
access  to  the  object,  but  its  SPUTCAPA  K-call  will  fail  (signal),  since  the  slot 
in  the  shared  object  wn.ll  no  longer  be  empty. 

For  certain  K-calls,  if  some  referenced  object  cannot  immediately  be 
locked,  the  K-call  will  fail.  To  do  otherwise  in  such  cases  would  allow  the 
possibility  of  deadlock.  For  the  same  reason,  any  K-call  that  accesses  a 
PROCEDURE  object  (except  when  an  LNS  is  being  incarnated  from  it)  must  be 
able  to  lock  the  procedure  immediately  or  else  the  K-call  will  fail. 

In  addition,  it  should  be  noted  that  there  are  some  "composite" 
operations,  e.g.,  SAPPENDCAPA,  STAICE,  SPASS,  etc.  (defined  in  section 
2.1.15.3).  These  operations  are  defined  in  terms  of  simpler  K-calls.  Note, 
however,  that  because  of  the  loclcing  phenomenon,  they  are  not  precisely 
equivalent;  if  they  were  done  as  a series  of  K-calls,  another  process  might  be 
able  to  access,  or  alter  one  of  the  C-lists  between  the  operations.  In  the 
composite  operations  these  actions  take  place  indivisibly,  with  both  the 
source  and  target  objects  locked  until  the  operations  are  complete. 


2.1.11  Memory  Addresses  and  the  Stack 

PDP-1 1's  as  modified  for  C.mmp  have  a 16  bit  address  space  and  a paged 
architecture.  Pages  are  8192  bytes  long.  The  lower  13  bits  of  the  IS  bit 
address  designate  a byte  within  a page.  The  high  order  3 bits  select  one  of  8 
pages  that  may  be  directly  addressable  at  any  given  time.  Page  0 is 
designated  the  stack  page  to  be  used  in  conjunction  with  the  PDP-11  SP 
register  and  is  treated  somewhat  specially  by  the  Kernel.  Hydra  contains 
various  K-calls  that  allow  the  user  to  change  other  pages  (virtual 
overlaying).  Details  can  be  found  in  section  4.7.  Details  on  the 
C.mmp  hardware  may  be  found  in  a separate  document  ([WB72]). 


Many  K-calls  require  one  or  more  arguments  to  be  memory  addresses. 
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Such  memory  addresses  are  expected  to  be  the  origin  (low  order  address)  of  a 
block  of  memory  from  which  the  Kernel  will  retrieve  information  or  into 
which  the  Kernel  will  store  information.  In  most  K-calls,  these  addresses 
can  be  anywhere  in  the  user's  immediately  addressible  page  set^  and  are 
referred  to  as  legitimate  memory  addresses.  Historically,  the  Kernel 
required  many  of  these  addresses  be  on  the  stack  page,  and  these  are  referred 
to  as  legitimate  stack  memory  addresses.  It  is  intended  eventually  that  all 
multiword  bloclts  of  data  (except  for  rights  restriction  masks)  will  be 
permitted  to  have  legitimate  memory  addresses  and  not  be  confined  to  the 
stack;  however,  this  document  represents  the  restrictions  as  of  November  4, 
1976. 

In  the  case  where  the  Kernel  demands  that  a legitimate  stack  memory 
address  be  used,  it  must  have  the  following  properties: 

> The  address  must  be  in  the  stack  page  (high  order  3 bits  of  the 
address  must  be  0). 

> The  block  of  memorj''  to  be  accessed  must  lie  within  the  active 
region  of  the  stack.  (When  an  LNS  begins  execution,  SP,  the  stack 
register,  is  set  to  point  to  an  initial  stack  location.  The  modified 
PDP- 1 1 hardware  insures  that  SP  can  never  be  set  higher  than  this 
initial  value  The  region  between  the  initial  SP  contents  and  the 
current  contents  of  SP  is  called  the  active  region  of  the  stack).  See 
figure  2.  Further  explanation  of  the  stack  limits  given  in  figure 
2 are  given  in  section  F.4. 

> The  address  must  be  on  a word  boundary  (low  order  bit  0). 

In  all  other  cases,  the  address  must  have  the  following  properties: 


> The  page  must  be  in  the  user's  current  BPS,  i.e.,  directly  addressible 
by  the  currently  executing  code. 

> The  page  must  be  writable  if  data  is  to  be  written  into  it.  (This  is 
controlled  by  auxiliary  rights  on  the  page;  see  section  4.5). 

> The  address  must  be  on  a word  boundary,  unless  a byte  address  is 
explicitly  permitted  for  the  K-call  being  specified. 


^ ® Knov/n  as  the  relocation  pa^e  sit  or  RPS,  discussed  In  sections  4.1  and  4.2. 


Recall  that  the  stack  grows  down,  I.e.,  towards  lower-numbered  addresses. 
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/ If  th.e  address  specifies  a bloclc  of  memory,  the  block  must  not  cross  a 
page  boundary. 


The  stack  may  also  be  directly  accessed  using  PDP-11  instructions 
since  the  stack  is  page  0.  The  modified  C.mmp  hardware  prevents  accesses  to 
page  0 above  the  LNS's  initial  stack  location;  however,  any  access  below  that 
is  allowed. 

7 

The  user  has  no  control  over  the  value  of  the  initial  stack  pointer  ? 
when  a procedure  is  invoked;  the  value  depends  upon  the  current  call  stack  ? 
in  the  process  and  the  amount  of  Kernel  data  placed  in  the  stack.  This  ? 
property  is  true  in  the  current  stack-page-per-process  implementation.  ? 
Future  revisions  of  the  implementation  may  change  this  property.  ? 

There  are  some  operations  in  the  I/O  system  (chapter  8) 
which  permit  the  user  to  specify  an  address  which  is  not  in  the  current  BPS. 
Such  addresses  are  used  only  in  special-purpose  I/O  handling  and  cannot  be 
specified  in  K-calls. 

Locations  #200-^377  comprise  the  Kernel  data  area.  When  signals, 
traps,  and  errors  occur,  certain  additional  information  is  placed  in  locations 
within  this  area.  (Section  F.5  lists  these  fields). 
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Figure  2:  Staclc  page  regions 


2.1.12  Indirect  K-calls 

Often  it  is  useful  to  be  able  to  build  up  the  argument  stack  for  a K-call 
independently  of  the  actual  K-call  itself  (especially  for  interpretive  and 
debugging  programs). 

The  special  K-call,  .‘EKi\LLIKDIP.ECT  provndes  this  function.  Its 
parameter  specifies  the  beginning  address  of  the  argument  stack  and  must  be 
a legitimate  stack  memory  address.  The  complete  specification  for  this  K- 
call  can  be  found  in  section  2.1.15.5.  Section  I contains  all 
details  necessary  for  constructing  the  argument  stack. 
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2.1.13  Conveations  for  K-call  Specifications 

There  is  a canonical  format  used  in  this  manual  to  descri'be  Kernel 
calls.  Each  K-call  description  consists  of  several  components: 


> The  K-call  name  and  its  formal  parameter  list.  K-calls  are  described 
in  terms  of  Bliss  macros.  See  appendix  K. 

> The  'parameters'  section.  Parameters  to  K-calls  fall  into  three  classes: 


> An  integer  value,  i.e.,  a 16-bit  value,  not  to  be  confused  with 
the  integer  used  as  a simple  index  to  denote  a capability  (see 
below). 

> A legitimate  memory  address.  In  some  cases  this  is  restricted 
to  be  a legitimate  stack  memory  address;  the  differences  and 
constraints  are  described  in  section  2.1. IT.  Where  a memory 
address  is  optional,  its  absence  is  denoted  by  0.  The  block  of 
memory  ■will  in  general  be  used  either  in  conjunction  with 
movement  of  data  to  or  from  a data-part  or  rights  restriction. 
See  sections  2.1.3  and  A.2.  As  a notational 
convention,  we  will  indicate  memory  locations  with  the 
symbols  'Mem'  (for  general  memory  locations)  and  'Smem' 
(for  stack  memory  locations).  We  will  suffix  these  symbols 
with  W or  R to  indicate  that  the  location  will  be  written  into 
or  only  read,  and  further  suffix  the  symbol  with  a number 
for  the  case  where  a block  of  memory  is  used.  Thus 
'SmemWlG'  indicates  a 16-word  block  of  data  will  be 
written  into  a valid  stack  memory  address.  When  the 
amount  of  data  transferred  is  a parameter  to  the  K-call,  the 
suffix  'Wn'  or  'Rn'  will  be  used,  with  a 'Count'  parameter  in 
the  K-call  specifying  the  actual  amount  of  data  transferred. 
Because  of  the  frequency  of  rights-restriction  masks,  the 
symbol  'SMemrts'  will  be  used  to  mean  'SmemR2'  in  such 
usage. 

> A denotation  for  a ^capability  - either  a simple  inde.x, 
(sometimes  negated^®  or  0 for  a special  effect)  or  a Path 
index,  or  a $CALL  parameter  (to  be  defined  in  section 


Of  Interejt  only  to  r.on-BLISS  users  and  those  using  the  Indirect  K-call,  see  section  2.1 .12. 
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2.2).  We  will  also  indicate  necessary  rights,  type  or 
kind  (object  reference  or  template)  for  the  target  capability, 
its  steps,  and  its  pretarget. 

Again,  as  a notational  convenience  we  will  often  indicate 
capabilities  to  be  "source"  capabilities  (the  targeted  object  is 
usually  not  altered  ^^)  and  use  the  designators  'SPath'  or 
'SIndex',  or  "destination"  capabilities  (the  targeted  object  is 
altered)  and  use  the  designators  'DPath'  or  'Dindex'. 

Unless  we  note  otherwise  in  the  specifications,  we  require  that  each 
step  in  a path  (capabilities  in  the  path  other  than  the  target  or 
pretarget)  be  an  object  reference  capability  with  SGETCAPARTS. 

We  will  not  list  restrictions  on  arguments  that  seem  obvious  or 
redundant  and  produce  obvious  signals  if  the  restrictions  are  not  met 
- most  notably,  indices  into  C-lists  or  data-parts  less  than  1 or 
greater  than  the  maximum  length  (see  section  2.1.7). 

> 'Effect'  is  the  effect  of  the  K-call  if  no  signal  occurs.  Except  for  a 
small  subcase  of  LKS  incarnation,  K-calls  that  fail  have  no  side 
effects. 

> 'Signals'  indicate  that  the  K-call  did  not  complete  normally.  Signals 
that  indicate  bad  arguments  or  arguments  that  denote  capabilities  of 
the  wrong  kind  or  type  or  having  inadequate  rights  are  not 
mentioned.  These  are  a possibility  in  almost  every  K-call  and  are 
described  in  section  F.  1.  For  a detailed  description  of  how 
an  LNS  may  handle  signal  conditions  see  section  2.3.2. 

> 'Result'  is  the  value  of  the  K-call  (returned  in  register  VREG  (RO)) 
assuming  no  signal  occurred.  (If  a signal  occurred,  the  value  of  the 
K-call  is  the  signal  value  instead.) 


2.1.14  Some  undefined  concepts 

There  will  be  a number  of  references  in  the  forthcoming  section 
(2.1.15)  to  concepts  which,  for  the  sake  of  exposition,  have  not  yet 
been  discussed.  The  comprehension  of  these  concepts  are  not  essential  for 
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Except  lit  certain  K-calls  which  transfer  (l.e.  delete  front  the  source  site)  capabilities  or 
exchange  Information;  In  the  former  case  the  source  operand  Indicates  where  the  capability 
Is  obtained;  In  the  latter  case  both  may  be  considered  destination  operands, 
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I understanding  the  following  section,  but  for  completeness  they  must  appear. 
I References  to  aliases,  freezing,  confinement,  and  the  associated  rights, 
$REALLYRTS,  $FREEZEFLAG,  and  SUNCFRTS  may  be  Ignored  unless  such 
! matters  are  truly  the  concern  of  the  moment.  Such  matters  are  dealt  with  in 
; depth  in  section  2.2.4. 

I 

i 

I 2. 1. 1 5 Specifications  for  Basic  Kernel  Calls 

I 

I 2.1.16,1  Inf ormational  K-calls 


SLNSLENGTH  ( ) 

Parameters: 

None 

Effect: 

None 

Result: 

Length  of  the  C-list  of  the  executing  LNS.  The  concept  of 
"length"  is  fully  described  in  section  2.1.7.  Note  that  the  length  of 
the  LNS  may  change  dynamically  during  program  execution. 


SCLENGTH  ( SPath  ) 


I 

I 


it 

? 

’I, 


Parameterai 


SPath 


- Path  index;  Pretarget:  SGETCAPARTS;  Target: 
object  reference,  SGETCAPARTS 


None 


Result: 

Length  of  the  C-list  of  the  object  referenced  by  SPath's 
Target.  The  concept  of  "length"  is  fully  explained  in  section  2.1.7. 
Intuitively  it  is  the  highest  index  of  a defined  capability. 


8DLENGTH  { SPath  ) 

Parameters: 


SPath  - Path  index;  Pretarget:  SGETCAPARTS;  Target: 
object  reference,  SGETDATARTS 
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Effect; 

None 

Besult! 

Size,  in  words,  of  the  data-part  of  the  object  referenced  by 
SPath's  Target. 


SOBJINFO  { SMemWlS,  SPath  ) 

Parameters: 

SMem W 1 6 - Legitimate  stack  memory  address 

SPath  - Path  index;  Pretarget:  SGETCAPAETS;  Target: 
defined  or  unbound 

Information  about  the  capability  targeted  by  SPath  is  stored 
in  the  16  word  block  of  memory  beginning  at  SMemWlS,  See 
Appendix  B for  the  format.  This  K-call  may  be  executed 
on  a unbound  target  without  causing  an  error. 

Signals: 


This  K-call  will  not  signal  an  unbound  target. 

Result; 

0 


8C0MPARE  ( SPath,  SIndex  ) 

Parameters: 

SPath  - Path  index;  Pretarget:  SGETCAPARTS;  Target: 
defined  or  unbound 

SIndex  - Simple  index,  defined  or  unbound,  or  0 
Effect: 

None 

Signals; 


This  K-call  will  not  signal  if  either  or  both  of  its  targets  are 
unbound. 

Result; 

A word  of  bits  which  indicate  how  the  capabilities  targeted 
by  SPath  and  SIndex  compare.  If  SIndex  is  0,  then  just  those  bits 
pertaining  to  the  capability  targeted  by  SPath  are  set.  See 
Appendix  C for  the  meaning  of  each  bit. 
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2.1,15.2  Simple  DATA  and  UNIVERSAL  Manipulation 


SGETDATA  ( MemWn,  SPath,  Disp,  Count  ) 


MemWn  - Legitimate  user  address  in  the  current  RPS 

SPath.  - Path  index;  Pretarget;  SGETCAPARTS;  Target: 
SGETDATARTS 

Disp  - Positive  integer  less  than  or  equal  to 
$DLENGTH(SPath) 

Count  - Positive  integer 
E£f2£ii 

Moves  up  to  Count  words  of  data  from  the  daia-part  of  the 
object  referenced  by  the  Target  of  SPath  to  the  block  of  memory 
beginning  at  MemWn.  The  data  is  copied  beginning  at  the  Disp’ih 
word  of  the  data-part  and  continuing  for  a total  of  Count  words  or 
until  the  end  of  the  data-part  is  reached.  Note  that  data  parts  are 
indexed  with  a 1 -origin,  i.e.,  the  first  word  in  the  data  part  of  an 
object  is  word  1. 

Result: 

Total  number  of  words  copied 


SPUTDATA  ( DPath,  MemRn,  Disp,  Count ) 


MemRn  - Legitimate  user  address  in  the  current  RPS 

DPath  - Path  index;  Steps  and  Pretarget:  SGETCAPARTS, 
SUNCFRTS;  Target:  SPUTDATARTS,  $MODIFYRTS 

Disp  - Positive  integer 


Count  - Positive  integer 
Effect: 

Copies  Count  words  of  data  beginning  at  MemRn  into  the 
data-part  of  the  object  targeted  by  DPath.  The  data  is  stored 
beginning  at  the  Disp'th  word  of  the  data-part.  The  data-part  will 
be  extended  if  necessary  to  contain  the  data.  If  Lq  was  the  length 
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(see  SDLENGTH)  before  the  $PUTDATA,  then  the  new  data-part 
length  will  be  nicLx(LQ,Disp+Count-l). 

Signals; 

$HySDBOUND-(Disp+Count)  would  exceed  either  the 
implementation-defined  limit  for  a data  part  (section 
A.4)  or  the  t5T>e-specific  limit  for  the  specific 
object  involved  (section  2.2.5). 

Result; 


SMAKEDATA  ( DPath,  MemRn,  Count,  Smemrts  ) 

Parameters; 

DPath  - Path  index;  Steps:  SGETCAPARTS,  $UNCFRTS; 

Pretarget:  SPUTCAPARTS,  SMODIFYETS;  Target: 
empty 

MemRn  - Legitimate  user  memory  address  in  the  current 
RPS 

Count  - Non-negative  integer 

Smemrts  - Legitimate  stack,  memory  address,  or  0 
Effect: 

Creates  a DATA  object  and  places  a capability  for  it  in  DPath's 
Target.  The  data-part  of  the  created  object  will  contain  the  Count 
words  of  data  copied  from  the  block,  of  memory  beginning  at 
MemRn.  The  capability  will  have  all  relevant  rights  except 
SREALLYRTS  and  SFREEZEFLAG  and  will  be  further  restricted  by 
the  contents  of  SMemrts  if  SMemrts  is  non-zero. 

Result: 

0 


# 
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SAPPENDDATA  ( DPath,  MemRn,  Count  ) 

Parameters; 

DPath  - Path  index;  Steps  and  Pretarget:  SGETCAPARTS, 
$UNCFRTS;  Target!  SAPPENDDATARTS, 

SMODIFYRTS 

MemRn  - Legitimate  user  memory  address  in  the  current  . 

RPS 

Count  - Positive  integer 

Copies  the  Count  words  of  data  from  the  block  of  memory 
beginning  at  MemRn  onto  the  end  of  the  data-part  of  the  object 
referenced  by  DPath's  Target.  If  Lq  was  the  length  of  the  data-part 
before  the  operation,  the  new  length  is  LQ+Count. 

Signals: 

See  SPUTDATA. 

Result: 

Displacement  in  data-part  of  DPath's  Target  of  first  data  word 
stored,  i.e.  one  greater  than  the  length  of  the  data-part  before  the 
store  occurred. 


SSETDLENGTH  ( DPath,  Count) 

Parameters: 

DPath  - Path  index;  Steps  and  Pretarget:  SGETCAPARTS, 

$UNCFRTS;  target:  SMODIFYBTS,  $PUTDATARTS 

Count  - Positive  integer 
Effect: 

Sets  the  length  of  the  data-part  of  the  target  object  to  be 
Count.  This  is  the  only  way  to  reduce  the  length  of  a data-part. 
The  value  may  be  any  value  between  0 and  the  maximum  data- 
part  length,  either  the  implementation  maximum  defined  in 
section  A.4  or  the  type-specific  limit  as  explained  in 
section  2.2.5.  If  the  data-part  length  was  less  than  Count, 
the  data-part  is  extended  and  filled  ViTith  zeroes. 

Signals: 

$HySDBOUND-Count  would  exceed  either  the  implementation- 
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defined  limit  for  a data  part  (section  A. 4)  or 
the  type-specific  limit  for  the  specific  object  involved 
(section  2.2.5). 

Result: 


SMAKEUNIVERSAL  ( DPath  ) 

Parameters: 

DPath  - Path  index;  Steps:  $UNCFRTS,  SGETCAPARTS; 

Pretarget:  $PUTCAPABTS,  SMODIFYBTS;  Target: 
empty 

Effect: 

Creates  a UNIVERSAL  object  and  places  a capability  for  it 
with  all  but  SREALLYRTS  and  $FREEZEFLAG  in  DPath's  Target. 
Result: 

0 

2.1.15.3  Simple  Mcinipulation  of  Capabilities 


3PASS  ( DPath,  SIndex,  SMemrts  ) 

Parameters: 

DPath  - Path  index;  Steps:  SGETCAPAETS,  SUNCFRTS; 

Pretarget:  SPUTCAPARTS,  $MODIFYRTS;  Target: 
empty 

SIndex  - Simple  index,  SDELETERTS;  if  DPath  is  not  simple, 
requires  $ENVRTS  as  well 

SMemrts-  Legitimate  stack  memory  address,  or  0 

Copies  the  capability  in  the  SIndex'th  slot  of  the  current  LNS 
to  DPath's  target,  restricting  rights  (if  SMemrts  is  nonzero) 
according  to  the  contents  of  SMemrts.  The  capability  at  SIndex  is 
then  made  unbound.  Future  attempts  to  access  the  target  of  SIndex 
will  (generally)  signal. 

Result: 

0 


r* 

>u 
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STAKE  ( Dlndex,  SPath  ) 

Param.eigi£i 

DIndex  - Simple  index,  empty 

SPath.  - Path  index;  Steps:  SGETCAPAilTS,  SUNCFRTSj 
Pretarget:  SKILLRTS,  SGETCAPARTS, 

SMODIFYRTS;  Target:  SDELETERTS 

Effect; 

Copies  the  capability  targeted  by  SPath  to  the  DIndex'th  slot 
of  the  current  LNS.  If  any  Step  or  Pretarget  in  SPath  laclcs 
$UNCFRTS,  then  DIndex  will  have  $UNCFRTS,  SMODIFYRTS  and 
SREALLYRTS  removed.  If  any  capability  in  SPath  lacks  SENVRTS, 
DIndex  will  have  SENVRTS  removed.  The  capability  targeted  by 
SPath  is  then  made  unbound.  Future  attempts  to  access  the  target 
of  Spath  will  (generally)  signal. 

Result: 

0 


3PUTCAPA  20  ( DPath,  SIndex,  Smemrts  ) 

Parameters! 

DPath  - Path  index-,  Steps:  SUNCFRTS,  SGETCAPARTS; 

Pretarget:  SMODIFYRTS,  SPUTCAPARTS;  Target: 
empty 

SIndex  - Simple  index.  Defined;  If  DPath  is  not  simple, 
requires  SENVRTS  as  well. 

If  DPath  and  SIndex  are  the  same,  then  none  of  the 
above  rights  requirements  holds,  rather  the 
capability  needs  SDELETERTS. 

Smemrts  - Legitimate  stack  memory  address,  or  0 

Copies  the  capability  in  the  SIndex'th  slot  of  the  current  LNS 
to  DPath's  target,  setting  SDELETERTS,  and  (if  Smemrts  is  nonzero) 
restricting  rights  according  to  the  contents  on  Smemrts. 

If  DPath  and  SIndex  are  the  same,  however,  the  rights  in  the 
target  are  simply  restricted  according  to  the  contents  of  Smemrts 
(if  Smemrts  is  nonzero). 


7 

7 

7 

? 


20 


Also  known,  for  historical  reasons,  as  SSTORE, 
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Result: 

0 


3GETCAPA  21  ( Dlndex,  SPath  ) 

Parameters: 

Dlndex  - Simple  index,  empty 

SPath  - Path  index;  Pretarget:  $GETCAPARTS;  Target: 

Defined 

Effect: 

Copies  the  capability  targeted  by  SPath  to  the  DIndex'th  slot 
of  the  current  LNS,  and  sets  SDELETERTS.  If  any  capability  in 
Target’s  Path  lacks  SUNCFRTS,  Dlndex  will  have  SUKCFRTS, 
SMODIFYRTS  and  SREALLYRTS  removed.  If  any  capability  in 
SPath  laclcs  $ENVRTS,  SENVRTS  will  be  removed  from  Dlndex. 
Result: 

0 


I SPASSAPPEND  { DPath,  SIndex,  Smerrirts  ) 

Parameters: 

i 

j DPath  - Path  index;  Steps  and  Pretarget:  SGETCAPARTS, 

I SUNCFRTS;  Target:  SMODIFYRTS, 

I $APPENDCAPARTS 

I SIndex  - Simple  index,  SDELETERTS,  SENVRTS;  defined 

j Smemrts  - Legitimate  stack,  memory  address  or  0 

I Effect: 

Appends  the  capability  in  the  SIndex’th  slot  of  the  current 
LNS  onto  the  end  of  the  C-list  of  the  object  referenced  by  DPath's 
target,  restricting  rights  (if  Smemrts  is  nonzero)  according  to  the 
contents  of  Smemrts.  The  capability  at  SIndex  is  then  made 
unbound.  Future  attempts  to  access  the  contents  of  Sindex  will 
j (generally)  signal. 

; BesuUi 

Slot  number  in  Target's  C-list  which  received  Sindex. 


? Also  known,  for  historical  reasone,  as  SLOAD. 

>• 
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SAPPENDCAPA  ( DPath,  SIndex,  Smemrts  ) 

Parameters; 

DPath  - Path  index;  Steps  and  Pretarget:  SUNCFRTS, 
$GETCAPARTS;  Target:  SMODIFYETS, 

SAPPENDCAPAJRTS 

SIndex  - Simple  index,  SENVRTS 

Smemrts  - Legitimate  stack  memory  address  or  0 
Effect; 

Appends  the  capability  in  the  SIndex'th  slot  of  the  current 
LNS  onto  the  end  of  the  C-list  of  the  object  referenced  by  DPath's 
target,  setting  $DELETERTS,  and  restricting  rights  (if  Smemrts  is 
nonzero)  according  to  the  contents  of  Smemrts. 

Result: 

Slot  number  in  Target's  C-list  which  received  SIndex. 


SVACATE  ( DPath  ) 

Parameters; 

DPath  - Path  index;  Steps:  SUNCFRTS,  SGETCAPARTS; 

Pretarget:  SMODIFYRTS,  SKILLRTS;  Target: 

SDELETERTS 

Effect: 

Deletes  the  capability  targeted  by  DPath.  See  section 
2.2.5  for  other  potential  effects  if  this  was  the  last 
capability  referencing  an  object.  The  slot  targeted  by  Dpath  is 
empty  but  defined  (see  sections  2.1.7  and  2.1.6). 

Result: 

0 


SDELETE  ( DPath  ) 

Parameters: 

DPath  - Path  index;  Steps:  SUNCFRTS,  SGETCAPARTS; 

Pretarget:  SMODIFYRTS,  SKILLRTS;  Target: 

SDELETERTS 

Effect; 

Deletes  the  capability  targeted  by  DPath.  See  section 
2.2.5  for  other  potential  effects  if  this  was  the  last 
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capability  referencing  an  object.  The  slot  targeted  by  Dpath  is  both 
empty  and  unbound.  This  may  also  affect  the  C-list  length  of  the 
C-list  containing  the  target.  See  sections  2.1.7  and  2.1.6. 

Result: 

0 


vSINTERCHANGE  ( DPath,  DIndex,  Smemrts  ) 


DPath  - Path  index;  Steps:  SUNCFRTS,  $GETCAPARTS 
Pretarget:  SMODIFYRTS,  SKILLRTS. 
SGETCAPAETS,  SPUTCAPARTS;  Target: 
$DELETERTS 

DIndex  - Simple  index,  SDELETERTS,  SENVTITS 


Smemrts  - Legitimate  stack  memory  address,  or  0 
Effect: 

Interchanges  the  capabilities  targeted  by  DPath  and  by 
DIndex.  Restricts  rights  (if  Smemrts  is  nonzero)  of  the  capability 
placed  into  DPath's  target  according  to  the  contents  of  Smemrts.  If 
any  Step  in  DPath  lades  SUNCFRTS,  DIndex  will  have  SUNCFRTS, 
SMODIFYRTS  and  SREALLYRTS  removed.  If  any  Step  lades 
SENVRTS,  DIndex  will  have  $EXVRTS  removed. 

Result: 

0 


* SRESTRICT  ( DPath,  Smemrts  ) 


DPath  - Path  index;  Steps:  SGETCAPARTS,  SUNCFRTS; 

Pretarget:  SGETCAPARTS,  SPUTCAPARTS, 

SKILLRTS,  SMODIFYRTS;  Target:  SDELETERTS; 

Target  may  be  empty 

SMemrts-  Legitimate  stack  memory  address,  or  0 

Restricts  the  rights  at  DPath’s  target  according  to  the 
contents  of  SMemrts.  If  SMemrts  is  0,  no  restriction  is  performed. 
BgSUlL 
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2.2.2  5.4  Date  and  Time  K-calls 


3GETGMT  {MemW4) 

Parameters; 

MemW4  - Legitimate  memory  address,  writeable. 

Effect:  - 

Returns  th.e  current  time  in  microseconds  in  relative 

to  system  date  0.  MemW4  is  a four-word  area  which  contains  the 
result  if  no  errors  have  occurred.  This  value  may  be  subsequently 
converted  to  other  formats  by  use  of  the  SGMTTOLOCAL  K-call. 
For  the  format  of  this  area,  see  Appendix  D. 

Rsmilii 

0 


3GNAMET0GMT  (MemW4,MemR4) 

Parameters: 

MemR4  - Legitimate  memory  address;  contains  the  global 
name  of  an  object 

MemW4  - Legitimate  memory  address,  writeable;  Note  that 
MemW4  may  overlap  or  be  identical  to  MemR4. 

Effect: 

Converts  the  global  name  at  MemB4  (such  as  is  obtained  from 
the  $0BJINF0  K-call,  see  section  2.1.15.1)  to  a corresponding  time 
in  microseconds  in  GMT  and  relative  to  system  date  0.  This  value 
could  be  used  in  the  $GMTT0L0CAL  K-call,  below,  to  obtain  a 
creation  date  and  time  for  the  object. 

Result: 

0 


inwlch  Mean  Time, 
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$GMTTOLOCAL  (MemWn,  Count) 

Parameters; 

MemWn  - Legitimate  memory  address,  writeable;  length,  is 
specified  by  the  Count  parameter 

Count  - Integer,  value  >4. 

Effect: 

The  first  four  words  at  the  location  specified  by  MemWn 
must  contain  a valid  GMT  time  value  (such  as  might  be  obtained 
from  the  SGETGMT  K-call,  above).  The  value  is  converted  to  local 
time  and  as  many  words  as  specified  above  the  GMT  date  are  filled 
in  with  this  information.  The  exact  format  is  given  in  Appendix 
D.  Note  that  if  a Count  larger  than  the  current 
implementation  maximum  is  given,  only  as  many  words  as  the 
maximum  specifies  are  produced;  the  balance  of  the  area  is 
unchanged.  However,  future  extensions  to  this  K-call  may  write 
in  these  words,  so  this  behavior  should  not  be  depended  upon. 
Note,  however,  that  future  extensions  will  never  write  more 
words  than  Count  specifies  so  users  are  guaranteed  compatibility 
between  future  extensions  and  existing  code. 

Signals: 

$HySGMT  - The  GMT  value  cannot  be  converted  within  the 
current  implementation-defined  limits  (dates  beyond 
the  year  2060,  approximately). 

Result: 

0 


SGETUPTIME  (MemW4) 

Parameteia; 

MemW4  - Legitimate  memory  address,  writeable. 

Effect: 

Returns  the  time,  in  units  of  microseconds,  of  the  GMT  time 
that  the  system  came  up  (relative  to  system  date  0).  MemW4  is  a 
four-word  area  which  contains  the  result  if  no  errors  have 
occurred.  The  value  may  be  subsequently  converted  to  other 
formats  by  use  of  the  SGMTTOLOCAJ..  K-call,  or  used  directly  to 
compare  previous  time  stamps  obtained  by  this  K-call. 

One  use  of  this  K-call  is  to  allow  the  user  to  determine  that 
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the  system  has  been  taken  down  since  the  last  time  the  time  stamp 
was  read.  This  permits  the  user  to  validate  complex  structures  of 
objects  and  data  which  might  have  been  damaged  if  the  system 
was  taken  down  when  they  were  presumed  to  be  in  an 
inconsistent  state. 

Result; 

0 


X 


SGETCLOCK  ( SMemW4  ) 

Parameters: 

SMemW4-  Legitimate  stack  memory  address 
Effect; 

Puts  a reading  of  the  system  clock  into  the  4 word  block  of 
memory  beginning  at  SMemW4.  See  Appendix  E for  the 
format. 

Note:  This  K-call  is  obsolete  and  has  been  superceded  by 
the  GMT  conversion  K-calls  given  previously.  It  is  included 
here  so  that  existing  code  may  be  understood. 

Signals; 

Result; 

0 


X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 


2.1.15.5  Indirect  K-call  specifications 


SKALLirsJDIRECT  (SMemRn) 

Parameters; 

SMemRn  - Address  of  the  start  of  the  K-call  parameter  list 
Effect: 

This  K-call  treats  the  data  at  SMemRn  as  if  it  were  stacked  as 
parameters  to  the  K-call.  For  details  on  the  format  see  section 
I. 

Signals: 

All  signals  are  possible  from  this  K-call.  A signal  may 
indicate  an  error  in  the  parameter  stack,  the  address  passed,  etc.,  or 
be  generated  by  the  K-call  described  at  SMemRn, 


Depends  upon  the  K-call  specified  at  SMemRn. 
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2.2.  The  Intermediate  Kernel 


2.2.1  Domain  Switching 

Let  us  consider  some  standard  protection  problems: 

> When  an  executing  program  wishes  to  invoke  another  program  (e.g. 
call  a subroutine),  the  caller  may  not  trust  the  called  program  and 
may  wish  to  isolate  it  in  a separate  environment  (LNS),  specifying  as 
arguments  only  capabilities  for  those  objects  in  its  own  LNS  that  it 
wishes  the  called  program  to  be  able  to  access. 

> A program  that  manipulates  a data  base  needs  capabilities  to  access 
the  data  base  but  it  should  never  be  possible  for  callers  of  the 
program  to  have  direct  access  to  the  data  base. 

» Since  no  program  except  those  belonging  to  the  data  base 
system  can  ever  access  the  data  base  representation  directly, 
the  system  implementors  may  feel  free  to  change  internal 
representations  at  any  point. 

* Since  no  program  except  those  belonging  to  the  data  base 
system  can  ever  modify  the  data  base,  no  user  car. 
inadvertently  or  maliciously  alter  the  structure  of  the  data 
base. 

* Since  no  users  can  access  the  contents  of  the  data  base 
without  using  the  data  base  system  as  an  intermediary,  the 
system  can  restrict  what  information  will  be  passed  out  to 
various  classes  of  users  and  what  modifications  it  will  accept 
from  various  classes  of  users. 


In  response  to  these  issues.  Hydra  provides  PROCEDURE  objects.  The  K- 

call  $CALL(Rtrn,Proc,Aj Aj^)  creates  a new  LNS  in  which  the  procedure's 

code  will  execute  and  transfers  control  to  it.  (Proc  denotes  a capability  for 
an  object  of  type  PROCEDURE,  A^  thi'ough  Aj^  denote  capabilities  to  be  passed 
as  arguments  to  the  called  procedure  and  Rtrn  denotes  a slot  where  the  called 
procedure  may  return  a capability.)  The  K-calls  $RETURN  and  SSUSPEND 
pass  control  back  to  the  calling  LNS,  optionally  returning  a capability. 

The  C-list  of  a PROCEDURE  contains  capabilities  that  will  be  duplicated 
in  each  LNS  incarnated  from  the  PROCEDURE.  These  are  called  inherited 
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capabilities^^  and  can  be  used  to  solve  the  data  base  problem  just  mentioned. 
In  addition,  some  of  the  capabilities  in  the  procedure's  C-list  are  parameter 
templates.  Capabilities  passed  as  arguments  to  the  procedure  will  appear  in 
those  slots  in  the  LNS's  C-list  where  parameter  templates  appeared  in  the 
procedure’s  C-list.  In  addition  to  specifying  where  CALL  arguments  appear 
in  the  incarnated  LNS,  parameter  templates  also  specify  a type  and  check- 
rights.  A $CALL  will  fail  [signal)  if  some  argument  is  not  of  the  same  type 
and  does  not  contain  the  minimum  rights  specified  by  the  check-rights  field 
of  the  corresponding  parameter  template^^.  The  initial  value  of  the  check- 
rights  field  in  a parameter  template  is  0 for  both  Generic  and  Auxiliary 
rights,  indicating  that  no  rights -checking  will  take  place.  See  section 
2. 2. 7. 2 and  the  $SETCHKRIGHTS  K-call.  A NULL  parameter  template 
may  be  used  in  cases  where  a number  of  different  types  of  objects  must  be 
accepted  as  parameters.  In  such  cases,  the  user  must  perform  the  tyT>e- 
checking  explicitly,  by  using  K-calls  such  as  SCOMPARE  and  $OBJINFO 
(section  2.1.15.1)  or  by  more  powerful  operations,  such  as  $MERGE, 
described  below  and  in  section  2.2.7.4. 

Procedures  can  be  used  to  construct  systems  of  programs  collectively 
known  as  protected  subsystems.  Consider  a Directory  system  where  users 
have  capabilities  for  directories  they  can  access,  but  because  the  'Directory 
subsystem'  maintains  the  directories  in  a special  private  format,  users  should 
not  be  able  to  directly  access  or  manipulate  their  directories  except  through 
the  set  of  PROCEDURES  which  comprise  the  'Directory  subsystem'. 
Therefore,  the  rights  [in  a capability]  to  a Directory  object  are  restricted  in 
such  a way  that  no  executing  LNS  outside  the  Directory  subsystem  can 
access  or  modify  a Directory  object.  However,  the  Directory  subsystem  itself 
must  be  able  to  access  and  alter  a Directory  object;  therefore  it  must  gain  the 
rights  necessary  to  do  this,  even  thotigh  the  [capability  for  a]  Directory 
object  passed  to  it  does  not  possess  these  rights.  Hydra  accomplishes  this 
through  a process  called  rights  amplification.  Capabilities  passed  as 
arguments  in  a $CALL  need  not  have  the  same  rights,  either  Generic  or 
Auxiliary,  in  the  incarnated  LNS  as  in  the  LNS  of  the  caller.  The  parameter 
template  may  specify  new-rights  which  may  be  greater  than  the  rights  of 


These  are  Inherited  from  the  PROCEDURE  object  which  created  the  LNS,  not  the  LNS  which 
Invoked  the  procedure.  This  point  Is  sometimes  unclear.  The  analogous  feature  In  some 
programming  languages  Is  the  ability  to  declare  how  "own"  variables  In  a procedure  or 
coroutine  are  to  be  Initialized  upon  an  Invocation. 


24 


Note  that  both  the  Generic  Rights  and  the  Auxiliary  Rights  fields  are  Included  In  the  rlghts- 
checklng. 
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the  capability  passed  as  an  argument;  in  the  incarnated  LNS,  the  capability 
will  have  the  new  rights.  Note  that  the  new  rights  may,  in  some  cases,  be 
less  than  the  rights  passed;  for  example,  an  information-delivering 
procedure  might,  for  the  peace  of  mind  and  protection  of  its  implementor, 
restrict  all  rights  which  would  allow  it  to  modify  the  "read-only"  objects 
passed  to  it  as  parameters.  This  would  prevent  it  from  accidently  modifying 
such  objects,  and  furthermore  might^°  prevent  any  procedures  it  calls  from 
modifying  the  objects. 

Figure  3 notes  how  this  solves  the  Directory  problem  through  the  use 
of  auxiliary  rights  and  parameter  templates  which  specify  new-rights.  The 
user's  capability  for  a Directory  does  not  contain  rights  which  allow 
manipulation  of  or  access  to  the  directories  directly.  Rather,  various 
procedures  of  the  'Directory  subsystem'  have  parameter  templates  which 
specify  these  rights  as  new-rights,  so  that  manipulation  or  access  of  a 
directory  can  only  take  place  in  the  protected  environment  of  the  'Directory 
subsystem'.  Auxiliary  rights  are  used  to  control  how  a Directory  may  be 
used.  Since  different  procedures  specify  different  check-rights  for 
Directories  passed  as  arguments,  auxiliary  rights  provide  a way  of 
specifying  procedural  protection.  Hydra  does  not  permit  unrestricted 
I creation  of  parameter  templates  which  specify  new-rights;  otherwise  the 
protection  afforded  by  the  directory  system  could  be  easily  circumvented. 
Templates  which  specify  new-rights  can  only  be  created  using  special 
I capabilities  (see  section  2.2.5),  and  since  templates  are  capabilities, 
their  dissemination  can  be  controlled.  In  the  above  case,  the  presumption  is 
that  only  PROCEDURES  of  the  'Directory  subsystem'  would  have  parameter 
templates  of  Directory  type  with  new-rights. 


Creation  of  an  LNS  and  transfer  of  control  to  its  code  can  be  separated. 
The  K-call  $MAKELNS  incarnates  an  LNS  from  a procedure  and  arguments, 

I while  the  K-call  SLNSCALL  transfers  control  to  the  LNS.  The  advantages  of 

having  such  pre-initialized  LNS's  are  efficiency  and  the  ability  to  build 
i coroutine  structures.  Once  an  LNS  SSUSPENDs,  it  may  be  SLNSCALLed  again. 

* Execution  continues  after  the  $SUSPEND.  The  LNS's  peiges,  its  C-list  and 

•J  registers  RO  and  PC  will  be  retained;  however,  the  rest  of  the  registers  will 

? be  destroyed 

i • 

? and  the  stack  will  be  reinitialized. 

I ' The  same  pre-initialized  LNS  may  be  used  by  more  than  one  process  at  a 


25  Depending  upon  which  rights  were  restricted. 
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Ampliticaticn  lamplata  desrtn  ® 1976  by  Brian  K.  Re 


Figure  3;  Example  of  a subsystem 

time,  but  not  simultaneously^®.  It  must  SSUSPEND  before  it  can  be 
$LNSCALLed  again.  The  creator  of  a procedure  can  control  whether  or  not  it 
can  be  passed  to  SMAXELNS,  whether  or  not  it  can  be  re-$LNSCALLed,  and 
whether  or  not  it  can  be  used  to  instantiate  a process. 


2.2.2  TEMPLATES  and  Merging 

The  process  of  comparing  a capability  to  a template  and  producing  a 
new  capability  is  called  merging.  It  is  useful  not  only  as  part  of  the  call 
mechanism,  but  at  other  times  as  well.  Hence,  there  are  capability  templates 


The  LNS  Is  serially  reusable  but  not  re-entrant.  Note  that  these  properties  apply  to  the  LNS 


and  not  the  code  Involved. 
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(for  general  merging  by  use  of  the  $MERfrE  K-call  described  in  section 
2. 2.7.4)  as  well  as  parameter  templates  (for  $CALL-time  merging). 
Templates  contain  two  flags: 

STemplateFlag  - 1 - Capability  template 

0 - Parameter  template 

$AmplifyFlag  - 1 - Amplify  rights  in  merging  (new-rights) 

0 - No  amplification 

These  flags,  if  set,  may  be  cleared  in  exactly  the  same  way  that  rights 
maj'’  be  restricted  (see  section  A.E).  Once  cleared,  they  may  not  be 
set  again.  Since  unlike  object  references,  templates  do  not  refer  to  specific 
objects,  there  is  little  need  for  templates  to  have  rights.  Therefore,  without 
much  conflict,  rights  and  new-rights  have  been  combined.  Even  when 
new-rights  are  specified,  there  are  certain  rights  that  cannot  be  amplified. 
This  is  true  of  the  Kernel  rights  SENVRTS,  $UNCFRTS,  $FREEZEFLAG, 
$MODIFYETS,  and  $REALLYRTS.  (Templates  never  have  SREALLYRTS.)  They 
will  appear  in  the  merged  capability  only  if  they  appear  both  in  the  new- 
rights  of  the  template  as  well  as  in  the  original  capability. 


2.2.3  NULLs  Revisited 

An  empty  slot  has  already  been  defined  as  a slot  containing  a NULL 
capability.  In  fact,  it  is  impossible  to  create  a NULL  object,  and  empty  slots 
actually  contain  NULL  templates. 

NULLs  have  one  auxiliary  right  predefined,  SUNBOUNDFLAG.  We  use 
the  term  unbound  to  mean  a NULL  template  with  both  SUNBOUNDFLAG  and 
$TemplateFlag  set.  When  an  object  is  initially  created,  its  C-list  is  set  to 
contain  all  unbound  capabilities  with  all  Kernel  rights^”^. 

The  length  of  a C-list  is  really  the  index  of  the  last  defined  slot  in  the 
C-list.  Hence  NULL  parameter  templates  or  NULL  templates  lacking 
$UNBOUNDFLAG  are  included  in  the  length. 


The  initial  ilze  of  the  C-Hst  of  such  objects  Is  a parameter  determined  at  the  time  the  TYPE 
representative  is  created;  see  sections  2.2.S  and  2. 2. 7.3.  For  Kernel  types,  It  Is 
the  implementation  maximum  given  In  section  A. 4. 
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2.2.4  Cozifiziemezit,  Freezing,  and  Revocation 

A number  of  Generic  rights  are  provided  to  solve  some  interesting 
, protection  problems.  $ENVRTS,  $MODIFYRTS,  and  $UNCFRTS  are  all  used  to 
! solve  variants  of  the  confinement  problem.  That  is,  they  may  be  used  to 
guarantee  that  capabilities  and  data  do  not  escape  from  particular  LNS's; 
those  LNS's  are  then  said  to  be  confined  or  partially  confined  with  respect 
to  the  information  against  whose  leakage  we  wish  to  protect. 

SENVRTS  can  be  used  to  guarantee  that  capabilities  are  not  stored  by  a 
callee  who  is  passed  the  capability.  Without  $ENVRTS,  the  capability  cannot 
be  placed  in  the  C-list  of  any  object  except  the  LNS  which  received  it  as  a 
parameter.  It  may  be  used  as  an  argument  to  an  LNS  which  the  callee  CALLs, 
but  $ENVBTS  cannot  be  gained  through  rights  amplification.  Additionally, 
whenever  a capability  is  loaded  into  an  LNS  through  any  path  in  which  some 
capability  laclts  $ENVRTS,  the  loaded  capability  will  have  $ENVRTS 
removed.  This  guarantees  that  if  a capability  without  SENVRTS  is  passed  to 
a procedure  neither  the  capability,  nor  any  capability  in  the  object  it 
references,  may  escape  from  the  caller's  environment.  Each  inherited 
capability  in  an  LNS  incarnated  from  a procedure  capability  lacking 
SENVRTS  will  have  SENVRTS  removed  as  well. 

j 

As  an  example,  capabilities  for  LNS's  never  have  SENVRTS  and  thus  can 
never  be  accessed  or  manipulated  outside  of  the  process  in  which  the  LNS 
has  been  incarnated. 

SMODIFYRTS  and  SUNCFRTS  can  be  used  to  protect  objects  from 
modification  through  capabilities  lacking  those  rights.  If  an  LNS  calls 
another  LNS  passing  a capability  lacking  SMODIFYRTS,  the  callee  cannot 
modify  the  accessed  object  through  that  capability  regardless  of 
I amplification.  This  is  assured  because  SMODIFYRTS  cannot  be  gained 
i through  rights  amplification  and  any  K-call  that  modifies  an  object  requires 
I a capability  for  that  object  with  SMODIFYRTS  as  well  as  other  relevant 
I rights. 

I 

i SUNCFRTS  also  cannot  be  gained  through  amplification  and  prevents 

modification  of  any  object  reached  through  the  C-list  of  an  object  referenced 
through  a capability  lacking  SUNCFRTS. 

Users  may  wish  to  guarantee  that  information  passed  to  an  untrusted 
procedure  will  not  be  leaked  to  another  user.  The  Generic  right  SUNCFRTS 
also  provides  this  guarantee.  Any  LNS  incarnated  from  a procedure 
capability  laclcing  SUNCFRTS  will  be  confined.  Each  capability  in  the  LNS 
inherited  from  the  Called  procedure  will  lose  SUNCFRTS,  SMODIFYRTS,  and 
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SREALLYBTS  (explained  later  in  this  section).  Confinement  is  then  provided 
in  the  following  way.  The  reader  may  note  that  any  K-call  which  modifies 
an  object  requires  that  the  capability  for  the  object  have  SMODIFYRTS  and 
that  other  capabilities  in  the  path  to  the  object  have  SUNCFRTS. 
Additionally,  whenever  a capability  is  loaded  into  an  LNS  through  a path 
where  some  capability  laclcs  SUNCFRTS,  the  loaded  capability  will  have 
$UNCFRTS,  $MODIFYRTS,  and  $REALLYRTS  removed.  Hence,  information 
and  capabilities  cannot  be  stored  by  a confined  LNS  through  any  capabilities 
except  those  passed  as  parameters  in  incarnating  the  LNS. 

Note  that  if  a procedure  capability  with  SUNCFRTS-  is  used  as  an 
argument  in  incarnating  a confined  LNS,  the  confined  LNS  will  be  able  to 
$CALL  an  unconfined  LNS  through  it.  Otherwise,  since  all  inherited 
capabilities  of  the  confined  LNS  lack  $UNCFRTS,  any  LNS  called  will  be 
confined  as  well. 

There  are  still  a small  number  of  ways  to  covertly  leak  a few  bits  of 
information  out  of  a confined  LNS.  It  would  be  counterproductive  to  list 
these.  However,  no  large  leakage  of  data  is  possible. 

X 

* Users  may  also  wish  to  guarantee  that  an  object  they  have  access  to  is 

* frozen.)  that  is,  the  object  and  all  objects  reached  by  taking  a path  through  it 

* will  r.  ever  be  modified,  even  by  concurrently  executing  LNS's  that  may  have 

* a capability  for  the  same  object.  The  flag  SFREEZEFLAG  is  used  like  a right 

* to  guarantee  that  an  object  is  frozen.  The  K-call  SFREEZE  acts  very  much 

* like  a $COPY,  except  that  it  also  sets  SFREEZEFLAG  and  eliminates  SUNCFRTS 

* and  SMODIFYRTS  from  the  copy  it  creates.  Since  SUNCFRTS  and 

* SMODIFITITS  cannot  be  gained  through  amplification,  all  capabilities  for  the 

* object  will  lack  them,  guaranteeing  that  the  object  will  never  be  modified 

* once  frozen.  SFREEZE  only  succeeds  if  all  capabilities  in  the  object's  C-list 

* are  already  frozen.  So  that  SFREEZEFLAG  can  represent  a guarantee  of 

* frozen-ness,  it  also  cannot  be  gained  through  amplification. 


Hydra  allows  objects  to  act  as  aliases  for  other  objects.  Accessing  such 
an  alias-iiig  object  actually  causes  access  of  the  aliased  object.  Aliases 
themselves  may  have  aliases,  allowing  up  to  23  levels  of  indirection.  The 
object  finally  accessed  at  the  end  of  the  alias  indirection  chain  is  called  the 
terminal  object  of  an  alias. 

An  alias  may  be  created  for  any  object,  and  a capability  will  be 
provided  for  the  aliasing  object  with  SREALLITITS.  With  SREALLYRTS,  the 
aliasing  object  may  be  re-aliased  with  the  SREALLY  operation  to  act  as  alias 
for  a different  object  or  even  for  no  object  at  all.  Thus,  if  a user  wishes  to 
share  a capability  for  an  object  with  another  user,  but  might  want  to  revoke 
the  capability  at  some  later  time,  he  need  simply  create  an  alias  for  the  object 
and  share  the  capability  for  the  alias. 
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To  guarantee  that  re-allying  cannot  be  used  to  illicitly  gain  rights,  * 
whenever  rights  are  restricted  in  a capability,  SREALLYBTS  are  removed  as  • 
well.  • 


2.2.5  Types,  Creating,  and  Erasing 


Objects  of  type  TYPE  represent  all  objects  in  the  equivalence  class  of  a 
given  type.  For  example,  the  object  whose  name  is  PROCEDURE  and  whose 
type  is  TYPE  represents  all  objects  whose  type  is  PROCEDURE.  There  is,  of 
course,  an  equivalence  class  for  objects  of  type  TYPE  represented  by  an 
object  whose  name  is  TYPE  and  whose  type  is  TYPE.  Some  of  these 
equivalence  classes  (for  Kernel-defined  objects)  are  illustrated  in  figure  4. 


objects 
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Figure  4;  Some  Generic-defined  objects 


Objects  of  type  TYPE  are  used  to  generate  templates  of  the  type  named 
by  the  TYPE  object.  A template  of  a given  type  is  then  used  in  creating  an 
object  of  that  type.  There  is  a single  object  in  the  system  whose  name  and 
type  are  both  TYPE  which  represents  all  the  objects  in  the  system  (including 
itself)  whose  type  is  TYPE.  (See  Figure  4.) 

The  way  to  create  a new  object  of  some  type,  say  FILE,  is  to  use  the  K- 
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call  $CREATE,  supplying  as  an  argument  a FILE  template  with.  SCREATERTS, 
called  a creation  template.  A FILE  template  can  first  be  gotten  by  using  the 
K-call  SMAKETEMPLATE,  supplying  a capability  for  the  FILE  TYPE  object 
with  $TEMPLATERTS. 

Note  that  as  a matter  of  policy,  a subsystem  may  not  allow  users  to 
have  access  to  creation  templates.  Instead,  a user  who  wishes  to  create  an 
object  must  call  upon  a procedure  in  the  subsystem  which  does  have  access 
to  the  creation  templates.  Thus,  the  subsystem  is  able  to  create  an  object  and 
initialize  it  in  a well-defined  way,  and  then  protect  it  from  the  user  by 
restricting  appropriate  rights.  The  subsystem  may  also  perform  resource 
control  or  accounting,  and  refuse  to  create  an  object  if  no  resources  are 
available  or  the  user  has  exceeded  some  quota. 

Initially,  Hydra  provides  templates  for  each  Kernel  type  (though  users 
may  not  directly  be  able  to  access  these).  These  templates  do  not  have  all 
Generic  rights,  but  rather  a restricted  set,  depending  on  the  type.  For  these 
rights  limitations,  see  section  A.5.  Note  that  one  does  not  need 
access  to  a Kernel  TYPE  object  in  order  to  obtain  templates  for  Kernel  types. 
See  the  SMAKETEMPLATE  K-call  in  section  2. 2.7.2. 

SCREATE  may  expect  some  additional  arguments  when  creating  an 
object  of  a Kernel  type^®.  For  example,  in  creating  a new  TYPE  object, 
SCREATE  expects  a memory  address  as  an  additional  argument.  The  Kernel 
will  use  the  information  in  that  block  of  memory  to  store  the  following  data 
in  the  data-part  of  the  TYPE  object: 

SCreatePNAME  - word  0 of  the  type's  print  name.  While  all  objects 
have  a 64  bit  bit  unique  name,  TYPE  objects  also  have  a 10- 
byte  print  name.  The  K-call  SOBJINFO,  given  a capability  for 
an  object,  produces  (among  other  information),  the  print  name 
of  its  type, 

$CreateCapaInit  and  $CreateCapaMax  - the  initial  length  of  the  C- 
list  (filled  with  truenulls)  and  the  maximum  length  of  the  C- 
list  of  any  object  of  the  type  created.  Either  or  both  of  these 
may  be  zero,  but  it  must  be  true  that 

SCreateCapalnit  < $CreateCapaMax. 

$CreateDataInit  and  SCreateDataMax  - the  initial  length  of  the  data- 
part  (zeroed)  and  the  maximum  length  of  the  data-part  of  any 
object  of  the  type  created.  As  with  the  C-list  limits, 
$CreateDataInit  < SCreateDataMax. 
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SCreateTempFla^  - an  indication  as  to  whether  objects  of  this  type 
are  to  be  retained  between  activations  of  Hydra.  If 
$CreateTempFlag  is  set  in  the  TYPE  representative  of  an 
object,  then  that  object  will  (effectively)  be  destroyed 
whenever  the  system  is  shut  down.  Such  objects  are  used  to 
contain  transient  status,  e.g.,  open-file  records. 

$CreateRetrieveFlag  - an  indication  of  whether  objects  of  this  type 
are  to  be  retrieved  when  all  references  to  the  object  are 
deleted  (see  following  paragraph). 

When  all  capabilities  for  an  object  have  been  deleted,  the  space 
occupied  by  the  object  is  normally  reclaimed.  However,  it  is  possible  to 
retrieve  such  objects  and  prevent  reclamation  on  a type-by-type  basis  (see 
RTRVFLAG  above).  The  K-call  $TYPERETRIEVE  returns  a capability  for  an 
object,  all  of  whose  references  have  been  deleted  (including  aliases).  To 
actually  reclaim  a retrievable  object,  the  K-call  $ERASE  rather  than 
SDELETE  must  be  used  to  delete  the  last  capability  for  the  object.  Aliasing 
objects  are  never  retrieved. 

The  fields  for  a type  creation  block  are  defined  in 
CREATE.REQ[N8  1 1HY97]. 


2.2.6  Protected.  Subsystems 

Since  protected  subsysteP2s  are  generally  built  around  a particular  type 
of  object  (e.g.  the  Directory  subsystem  mentioned  earlier).  Hydra  provides  a 
way  to  use  a subsystem  without  unnecessarily  proliferating  capabilities  for 
the  procedures  which  define  it. 

The  C-list  of  a type  object  is  used  to  implement  protected  subsystents 
easily  by  listing  the  procedures  which  define  it,  and  supplying  access  to 
those  procedures  through  the  K-call  STYPECALL. 

If  the  Ndx'th  capability  in  the  current  LNS  is  of  type  T,  and  we  use  the 
notation  Tj  to  indicate  the  j'th  capability  in  the  C-list  of  the  T-TYPE  object, 
then  STYPECALL  (Rtrn,Ndx,j,a2,...,aj^^)  is  the  same  as 
$CALL(Rtrn,Tj,a2,...,aj^).  See  figure  5. 


There  are  several  advantages  to  using  the  STYPECALL  mechanism.  Two 
major  advantages  are: 

> Users  do  not  have  direct  access  to  capabilties  for  the  subsystem 
procedures.  Thus  new  procedures  may  be  installed  by  changing  the 
capabilities  in  the  TYPE  object.  This  makes  management  of  complex 
systems  much  easier. 
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object  of  type  TYPE 


t>TYPECALL(2,3,4,<args>) 

Figure  5:  A STYPECALL  e:cample 

> Standard  interfaces  can  be  protuded.  For  example,  the  convention 
may  be  adopted  that  slot  2 of  the  TYPE  object  contains  the  creation 
procedure  capability. 


2,2.7  Specifications  for  Intermediate  Kernel  X-calls 
2.2.7. 2 Creation  of  TYPE  objects 


8CREATE  (DIndex,  Slype,  SMemRlO) 


DIndex  - Simple  index,  empty 

SType  - Simple  inde.x,  TI^PE  template,  SCREATERTS. 

SMemRlO  - Legitimate  stack  memory  address  '"or 
details  of  contents,  see  section  2.2.5. 


y--  •*’frift'-T,rffr'<m7iM^-’friir<^^  rirtri-%ii ' 
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Effect: 

Creates  a TYPE  object  for  a user-defined  type.  The  type  print 
name,  C-list  limits,  data-part  limits,  temporary  fla^  and 
retrievability  flag  are  all  set  according  to  the  contents  of 
SMemRlO. 

Signals: 

This  K-call  will  signal  if  any  of  the  parameters  in  the  type 
creation  block  are  out  of  range  or  inconsistent.  The  index  of  the 
offending  word  for  the  signal  will  be  placed  in  SSIGDATA. 
SHySTYPEBOUND  - One  of  SCreateCapalnit,  SCreateCapaMax, 

SCreateDatalnit  or  $CreateDataMax  larger  than  the 
implementation-defined  maximum;  or 
SCreateCapalnit  > SCreateCapaMax  or 
SCreateDatalnit  > SCreateDataMax. 

Result: 

0 


SCHANGETYPESPECS  (DIndex,  SMemRlO) 


Parameters: 


DIndex  - TYPE  object  reference;  Steps  and  Pretarget: 
$GETCAPARTS,  SUNCFRTS;  Target: 

SCHAWGETYPERTS,  SMODIFYRTS 

SMemRlO  - Legitimate  stack  memory  address 

Effact: 

Allows  the  parameters  set  at  creation  of  a TYPE  object  to  be 
altered.  Note  that  these  changes  will  affect  only  future  creations 
done  for  objects  of  this  TYPE.  The  only  change  to  existing  objects 
is  that  the  print  name  is  changed.  Note:  if  a -1  (#177777)  is 
stored  in  a word  of  the  type  specification  block,  the  contents  of 
that  field  in  the  TYPE  object  is  not  altered. 

Signalai 


This  K-call  will  signal  if  any  of  the  parameters  in  the  type 
specification  block  are  out  of  range  or  inconsistent.  The  index  of 
the  offending  word  for  the  signal  will  be  placed  in  SSIGDATA. 
SHySTYPEBOUND  - One  of  SCreateCapalnit,  SCreateCapaMax, 

SCreateDatalnit  or  SCreateDataMax  larger  than  the 
implementation-defined  maximum;  or 
SCreateCapalnit  > SCreateCapaMax  or 
SCreateDatalnit  > SCreateDataMax. 
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Result: 

0 

2. 2. 7. 2 TEMPLATE  Manipulation 


SMAKETEMPLATE  ( DPath,  SIndex,  Smemrts  ) 

Parameters: 

DPath  - Path  index;  Steps:  SGETCAPARTS,  SUNCFP.TS; 

Pretarget:  SPUTCAPARTS,  $MODIFYRTS;  Target: 
empty 

SIndex  - Simple  index,  type  TiTE,  $TEMPLATERTS  or  a 
negative  integer  (see  below) 

Smemrts  - Legitimate  staclt  memory  address,  or  0 
Effect! 

If  SIndex  is  a simple  index,  then  SMAICETEMPLATE  ,'aces  a 
template  in  DPath's  Target  whose  type  is  the  name  of  the  SIndex'th 
capability  in  the  current  LKS.  The  template  will  only  have 
SUNCFRTS  set  if  SIndex  has  SUXCFRTS.  The  template  will  have  all 
other  flags  and  rights  (both  Generic  and  Auxiliary)  set  except  for 
SREALLTOTS. 

If  SIndex  : ..'gative,  then  a template  for  the  (-SIndex)'th 

Kernel  type  is  placed  in  DPath's  Target  with  STemplateFlag  set  as 
well  as  various  rights  depending  on  the  type.  (See  section 
A.5.)  The  first  13  types  are  the  predefined  Kernel  types. 
The  symbols  which  map  these  names  into  types  are  described  in 
section  A.5  and  in  the  Bliss  require  file 
TY?ES.REQ[N81 1HY97].  Note  that  the  sjonbols  given  in  this  file 
are  positive  integers,  and  must  be  negated  by  the  user  tvhen  used 
in  this  K-call. 

In  either  case,  the  rights  of  the  new  template  are  further 
restricted  according  to  the  contents  of  Smemrts  (if  Smemrts  is 
nonzero). 

Result: 


0 
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SSETCHKRIGHTS  ( DPath,  SMemrts  ) 

Parameters: 

DPath  - Path  index;  Steps:  SGETCAPARTS,  SUNCFRTS; 

Pretarget:  SGETCAPARTS,  SPUTCAPARTS, 

SKILLRTS,  SMODIFYRTS;  Target:  template, 

SDELETERTS 

SMemrts-  Legitimate  stack  memory  address 

Effect; 

Sets  the  check-rights  of  the  template  at  DPath  according  to 
the  contents  of  SMemrts. 

Result: 

0 

Z.Z.7.3  Object  Manipulation 

SCREATE  ( Dlndex,  Slndex,  <arguments>  ) 

Parameters: 

Dlndex  - Simple  index,  empty 

SIndex  - Simple  index,  template,  SCREATERTS;  must  not  be 
NULL;  Also  requires  SUNCFRTS  if  the  type  is 
Retrievable 

- For  description  of  additional  <arguments>  (only 
applicable  when  SCREATEing  a Kernel  object)  see 
section  A.  5. 

Effect; 

Creates  a new  object  of  the  same  type  as  SIndex  and  places  a 
capability  for  it  in  Dlndex.  The  rights  in  Dlndex  are  the  same  as 
those  in  SIndex  except  that  SFREEZEFLAG  will  be  removed, 
SDELETERTS,  SENVRTS,  and  SMODIFYRTS  will  be  added, 
SUNCFRTS  will  be  added  unless  SIndex  is  a procedure  template  and 
the  current  LNS  is  confined. 

Result: 


0 
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SCOPY  ( DIndex, 


SIndex,  <argLiments>  ) 


Parameters: 

DIndex  - Simple  index,  empty 

SIndex  - Simple  index,  object  reference,  SCOPYETS 


- For  description  of  additional  <arguments>  (only 
applicable  when  SCOPYing  a Kernel  object)  see 
section  A.5. 

Effect! 

Creates  a new  object  of  the  same  type  as  SIndex  and  places  a 
capability  for  it  in  DIndex.  In  addition,  the  contents  of  the  C-list 
and  data-part  of  the  new  object  will  be  the  same  as  those  of  the 
original. 

The  rights  of  the  new  capability  in  DIndex  will  be  exactly 
the  same  as  those  for  SIndex  plus  SDELETERTS,  unless  the  object  is 
of  a Kernel  type,  in  which  case  additional  rights  may  be  added. 
Note  that  some  Kernel  types  cannot  be  copied.  See  section 
A.  5 for  details. 

RgSULli 

0 


* SDESTROY  ( DPath  ) 

* Parameters: 

X 

* DPath  - Path  index;  Steps  and  Pretarget:  SGETCAPARTS, 

* $UNCFRTS;  Target:  object  reference, 

* SMODIFYRTS,  SOBJRTS 

* Effect: 

* Destroys  the  object  referenced  by  the  Target  and  deletes  all 

* capabilities  in  the  object's  C-list. 

* Future  accesses  of  the  object  will  fail  with  either 

* SHySCBOUND  or  SI-IySDBOUND  signals. 

* When  the  last  capability  for  the  object  is  deleted,  the  object 

* will  not  be  retrieved. 

Result: 


i 
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SSWITCH  (DFath,  DIndox) 


DPath  - Path  iadex;  steps  and  pretarget:  SGETCAPAHTS, 
SUNCFRTS;  Target:  object  reference, 

SMODIFYBTS,  $OBJRTS,  SUNCFRTS 

DIndex  - Simple  index,  same  type  as  DPath's  target, 

$OBJRTS,  $UNCFRTS,$MODIFYRTS 

Effect: 

Switches  the  C-list  and  data-part  of  the  objects  referenced  by 
DPath's  target  and  DIndex. 

Signals; 

$HySCANTLOCK-The  object  referenced  by  DIndex  cannot  be 
immediately  locked. 

Result; 

0 


3FREEZE  ( DIndex,  SIndex,  <arguments>  ) 


DIndex  - Simple  index,  empty 


SIndex 


- Simple  index,  object  reference,  SOBJRTS, 
SMODIFYRTS;  SIndex  must  not  be  an  alias;  each 
capability  in  C-list  of  the  object  must  have 
SFREEZEFLAG 

- For  description  of  additional  <arguments>  (only 
applicable  when  performing  SFREEZE  on  a Kernel 
object)  see  section  A.5. 


EfffiCii 


Performs  a $COPY  of  the  object,  then  sets  SFREEZEFLAG  and 
turns  off  $UNCFRTS  and  SMODIFYRTS  in  DIndex.  Otherwise  the 
same  as  $COPY. 

Signals; 

$HySFREEZE-  Some  capability  in  the  object's  C-list  is  not  frozen. 

SSIGDATA  indicates  the  index  of  the  last  such 
capability. 

SHySNOTUNIQUE-DIndex  is  not  the  only  reference  to  the  object. 
SHySALLAS  - DIndex  references  an  alias. 

Result: 
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8MAKEALIAS  ( DIndex,  SIndex  ) 


DIndex  - Simple  index,  empty 

SIndex  - Simple  index,  object  reference 
Effect: 

Creates  an  object  in  DIndex  of  th.e  same  t5T>e  as  SIndex  to  act 
as  an  alias  for  the  object  referenced  by  SIndex.  Any  future 
references  to  to  the  new  object  (unless  changed  by  SREALLY)  will 
in  fact  access  SIndex's  Terminal  object.  DIndex  will  have  the  same 
rights  as  SIndex  except  SDELETERTS  and  SREALLYRTS  will  be 
added  and  it  will  not  have  SFREEZEFLAG. 

RgsuUi 
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SREVOKE  ( DIndex  ) 


DIndex  - Simple  index,  SREALLYRTS 
Effect: 

Revokes  alias  until  re-ally-ing  occurs.  Future  references 
through  the  alias  will  fail  with  signal  SHySNOALIAS. 

Result: 

0 


SREALLY  ( DIndex,  SIndex  ) 


DIndex  - Simple  index,  SREALL'xRTS  (insures  aliasing 
object) 

SIndex  - Simple  index,  must  reference  DIndex's  original 
alias.  SInde.x,  except  for  SDELETERTS  and 
SREALLYRTS,  must  have  at  least  all  the  rights 
that  DIndex  has. 


Re-allies  the  object  referenced  by  DIndex  to  be  an  alias  for 
the  object  referenced  by  SIndex. 

Result; 

0 


ih*  — 
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STYPERETRIEVE  ( DIndex,  SIndex  ) 

Parameters: 

DIndex  - Simple  index,  empty;  or  0 

SIndex  - Simple  index,  TYPE  object  reference,  $UNCFRTS, 
SRETRIEVERTS 

Effect; 

If  DIndex  is  not  zero,  retrieves  a capability  for  an  object  of 
the  type  named  by  SIndex,  all  of  whose  references  have  been 
deleted.  The  Kernel  maintains  the  retrieval  queue  for  each  object 
in  FIFO  order.  The  retrieved  capability  has  all  rights  except 
$FREEZEFLAG  'and  SREALLYRTS  (aliasing  objects  are  not 
retrieved).  If  DIndex  is  zero,  the  K-call  is  executed  for  its  result 
value  only. 

Result: 

Number  of  objects  in  SIndex's  type's  retrieval  queue, 
including  object  retrieved,  if  any.  Note  a result  of  0 indicates  no 
object  was  retrieved. 


j SERASE  ( DIndex  ) 

I Parameters:  * 

I DIndex  - Simple  index,  must  be  only  reference  to  object,  • 

SOBJRTS,  SDELETERTS 

I Effect:  » 

: Deletes  last  reference  to  an  object  without  placing  it  in  its  * 

f t3Tpe's  retrieval  queue.  Also  deletes  each  capability  in  the  object’s  * 

I'  C-list.  (If  the  capability  is  for  an  aliasing  object,  or  no  retrieval  is  * 

indicated  for  the  type,  simply  deleting  the  last  reference  to  the  * 
object  has  the  same  effect  as  SERASEing  it.)  * 

- Signals:  » 

I;  SHySNOTUNIQUE-DIndex  is  not  the  only  reference  to  the  object  * 


Result: 
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2. 2.7. 4 The  CALL  Mechanism 


8MERGE  ( Dlndex,  STempi,  SPath  ) 

Parameters: 

DIndex'  - Simple  index,  empty 

STempi  - Simple  index,  template,  STemplateFlag 

SPath  - Path  index-.  Pretarget:  SGETCAPARTS;  Target: 

defined,  rights  must  contain  all  those  specified  by 
checK-rights  field  of  STempi.  If  STempi  is  not 
NULL,  m.ust  be  an  object  reference  and  must  be  of 
the  same  type  as  STempi.  If  STempi  is  NULL,  may 
be  of  any  type  and  may  be  either  an  object 
reference  or  a template. 

Effect: 

Copies  the  capability  targeted  by  SPath  to  the  DIndex'th  slot 
of  the  current  LNS  and  sets  SDELETERTS.  If  SPath's  Target  is  a 
capability  for  an  aliasing  object  and  STempi  has  SAmplifyFiag  set, 
a capability  for  the  alias's  terminal  object  is  copied  instead. 

If  STempi  has  SAmplifyFiag  set,  STempl's  (new-rights)  are 
copied  to  Dlndex,  except  for  SENlfP.TS,  SUNCFRTS,  SMODIFYBTS 
and  SFREEZEFLAG  which  must  appear  in  SPath's  Target  as  well. 

If  any  capability  in  the  Path's  steps  or  pretarget  lached 
SUNCFRTS,  then  SMODIFYRTS,  SUNCFRTS  and  SREALLYRTS  will 
be  removed  from  Dlndex.  If  any  capability  in  the  SPath  lacked 
SENVRTS,  then  SENVRTS  will  be  removed  from  Dlndex, 

Signals: 

SHySCKECXRTS-Check-rights  failure 

SHySMERGE-  STempi  is  not  a template  or  does  not  have 
STemplateFlag  set. 

SHySSTYPE  - Types  of  SPath's  Target  and  STempi  are  not  the  same. 

RgsuUi 
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SMAKELNS  ( DIndex,  Nproc,  <arguments>  ) 

Parameters: 

DIndex  - Simple  index,  empty 

Nproc  - Simple  index,  procedure  object  reference; 
SLNSRTS 

The  0 or  more  <arguments>  must  each  be  of  the  following 
form: 

> $PATH(SPath) 

Path  index;  Pretarget:  SGETCAPAETS; 
Target:  Requires  SENVRTS  if  Nproc  has 
$PROCESSRTS 

> $RESTRICTION  ( SPath,  Smemrts  ) 

SPath:  as  for  SPATH 

Smemrts:  Legitimate  staclt  memory 
address,  or  0 

> STRANSFER  ( SPath,  Smemrts  ) 

SPath:  Path  index; 

Steps:  SUNCFRTS,  SGETCAPARTS; 
Pretarget:  SMODIFYRTS,  SGETCAPARTS, 
SKILLRTS; 

Target:  SDELETERTS,  also  requires 
SENVRTS  if  Nproc  has  SPROCESSRTS. 
Smemrts:  Legitimate  stack  memory 
address,  or  0 

> SMEMDATA  ( MemRn,  Count ) 

MemRn:  Legitimate  user  memory  address 
Count:  Positive  integer 

> SSTKDATA  ( <data> 

<data>:  0 or  more  expressions,  each  of 
which  generates  one  word  of  data 


An  obsolete  eontruct  which  Is  included  here  for  completeness,  Users  may  encounter  it  In 
older  code  and  confuse  It  with  SSTACilDATA. 
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> $STACKDx\TA  ( <data>  ) 

<data>:  0 or  more  expressions,  each  of 
which  generates  one  word  of  data 

> $LKS() 

> SLNSRESTRICT  ( Smemrts  ) 

Smemrts:  Legitimate  stack  memory 
address,  or  0 

Arguments  $LNS  and  SLNSRESTRICT  are 
permitted  only  if  Nproc  does  not  have 
both  SPROCESSRTS  and  SENVRTS.  The 
capability  denoted  by  each  argument  must 
also  satisfy  the  requirements  of  its 
corresponding  parameter  template  (see 
SMERGE). 


An  LNS  is  incarnated  from  the  procedure  and  arguments  and 
a capability  for  it  is  placed  in  DIndex  with  SEELETERTS.  In 
addition  it  will  have  SUNCFRTS  and  SFREEZEFLAG,  and  the 
auxiliary  rights  SLNSRTS  and  SPROCESSRTS  if  Nproc  does.  If 
Nproc  lacks  SPROCESSRTS  or  SENVRTS,  the  Capability  for  the  LNS 
will  lack  SENVRTS. 

The  LNS  will  be  made  confined  if  Nproc  laclcs  SUNCFRTS. 

All  capabilities  in  the  C-list  of  the  PROCEDURE  which  are 
either  object  references  or  capability  templates  (STemplateFlag 
set)  are  copied  to  the  same  slot  in  the  C-list  of  the  incarnated  LNS. 
These  are  the  inherited  capabilities.  If  Nproc  laclts  SUNCFRTS, 
each  of  these  will  have  SUNCFRTS,  SMODIFYRTS  and  SRE.\LLYRTS 
removed.  If  Nproc  laclts  SENVRTS,  each  inherited  capability  will 
have  SENVRTS  removed. 

Parameter  templates  in  the  C-list  of  the  PROCEDURE  are 
capabilities  specified  by  the  arguments.  Arguments  are  matched 
with  parameter  templates  in  descending  slot  number  order.  The 
"rightmost"  parameter  is  merged  to  the  highest-numbered 
parameter  slot,  the  "ne.xt-rightmost"  parameter  to  the  next- 
highest-numbered  parameter  slot,  etc.,  until  all  parameters  have 
been  merged.  If  insufficient  parameters  are  provided,  the 
remaining  lower-numbered  parameter  slots  are  filled  with 
unbound  templates  (see  section  2.3.1). 

The  capabilities  that  will  be  placed  in  the  parameter  slots  of 
the  LNS  are  the  result  of  SMERGEing  the  parameter  template  with 
a capability  specified  by  the  corresponding  argument.  For  details 
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of  each,  individual  merge,  see  the  ‘Effect’  part  of  the  SMERGE  K- 
call.  As  noted,  arguments  come  in  7 flavors.  The  capabilities  they 
specify  and  additional  side  effects  are  as  follows: 

> $PATH:  Capability  is  SPaih's  Target. 

> $RESTRICTION:  Capability  is  SPath's  Target,  restricted  by 
the  contents  of  Smemrts  if  Smemrts  is  non-zero. 

> $TRAI\ISFER:  Capability  is  SPath's  Target,  restricted  by  the 
contents  of  Smemrcs  if  Smemrts  is  non-zero.  In  addition, 
the  capability  at  SPath's  Target  is  deleted.  (N.B.  Use 
wisely,  because  if  the  K-call  fails  the  capability  may  be 
lost.)  This  option  is  equivalent  to  the  $PASS  K-call. 

> $MEMDATA:  Capability  is  for  a newly  created  DATA  object 
with  all  rights  but  SFREEZEFLAG  and  $REALL\TITS.  The 
data-part  of  the  new  object  will  contain  the  Count  words 
of  data  copied  from  the  block  of  memory  beginning  at 
MemRn. 


> $STKDATA:  Capability  is  for  a newly  created  DATA  object  X 
with  all  rights  but  SFREEZEFLAG  and  SREALLYIRTS.  The  X 
data-part  of  the  new  object  will  consist  of  '<data>'  in  X 
reverse  order.  Thus  SSTKDATA  (1 1,22,33)  produces  a data  X 
object  containing  words  33,  22,  and  1 1 in  positions  1,  2,  X 
and  3,  respectively.  X 


> SSTACKDATA:  What  SSTKDATA  was  really  meant  to  be. 
Creates  a capability  for  a newly-created  DATA  object  with 
all  rights  but  SFREEZEFLAG  and  SREALLTTITS.  The  data 
part  of  the  new  object  will  consist  of  '<data>'  in  the 

> correct  order.  SSTACKDATA  (1 1,22,33)  produces  a data 

object  containing  words  11,  22,  and  33  in  positions  1,  2, 
V and  3,  respectively. 

|- 

If  > SENS:  Capability  is  for  the  caller's  LXS  with  SDELETERTS, 

f-  SMODIFYRTS,  SUNCFRTS,  SGETCAPARTS,  SPUTCAPARTS, 

•.  . $/?lPPEXDCAPAHTS,  SKILLRTS,  SGETCBRTS,  SSETCBRTS, 

SGETSTACKETS,  and  SPUTSTACKRTS. 

> SLNSRESTRICT:  Capability  is  as  in  SENS  with  rights 


additionally  restricted  by  the  the  contents  of  Smemrts  if 
Smemrts  is  non-zero. 
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Sigaalsi 

$HySFARG  - Too  few  arguments.  SSIGDATA  indicates  the 
minimum  number  of  arguments  acceptable. 

SHySMARG  - Too  many  arguments.  $SIGDATA  indicates  the 
maximum  number  of  arguments  acceptable. 
$HySCANTCONFINE-LNS  is  not  allowed  to  be  made  confined.  (See 
section  2.3.1.) 

If  an  argument  is  bad  or  any  merge  failed,  the  usual  signal 
will  be  generated  with  $HySMAICELNS  or'ed  in  as  well.  In 
addition,  the  fixed  location  $SIGDATA  in  the  stack  page  will 
contain  the  index  of  the  affected  slot  in  the  incarnated  LNS  in  its 
low  order  byte  and  the  number  of  the  affected  argument  in  its 
high  order  byte. 

Result: 

0 


SLNSCALL  { Dlndex,  NIns  ) 


DIndex  - Simple  index,  empty 

Nlns  - Simple  index,  LNS  object  reference,  SLNSRTSj 

The  LNS  must  be  "usable"  (see  sections  2.3.2  and 
3.1.1) 

Effect: 

The  LNS  is  called  and  execution  begins  in  its  environment. 
When  the  called  LNS  $SUSPENDs,  it  may  specify  a capability  to  be 
returned.  If  DIndex  is  not  zero,  it  designates  the  slot  where  that 
capability  will  be  put.  If  DIndex  is  zero,  a returned  capability  is 
simply  discarded. 

Signals; 

SHySNOSTACK-Inadequate  stack  space  available  to  run  the  LNS 
(see  section  2.3.1).  SSIGDATA  contains  amount 
of  additional  stack  space  needed. 

$HySCONTROL-Callee  returned  by  'Punting  a Control'  rather  than  a 
SSLTSPEND  (see  section  2.3.1). 

$HySCANTLOCK-LNS  is  currently  in  use  (see  section  3.1.1). 
$HySREUSE  - LNS  may  not  be  reused  (see  section  2.3.3). 

For  paging-related  signals,  see  section  4.7.1. 

When  the  callee  SSUSPENDs,  it  specifies  a return  value.  If 
that  value  is  negative,  it  is  treated  as  a signal. 
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Value  returned  by  the  callee 


3CALL  ( DIndex,  Sproc,  <arguments>  ) 

Farameterai 

DIndex  - Simple  Index,  empty,  or  0 

Sproc  - Path,  procedure  object  reference,  SCALLRTS 

- Specifications  for  <arguments>  are  exactly  as  for 
SMAKELNS. 

Effect: 

The  effect  is  almost  equivalent  to  the  sequence 

SMAKELNS  < Nproc,  <arguments>  ){ 

SLNSCALL  < DIndex,  * ). 

That  is,  the-  Kernel  incarnates  the  LNS  and  calls  it,  without  the 
caller  ever  having  a capability  itself  for  the  incarnated  LNS.  The 
only  difference  is  that,  unless  required  by  check-rights  in  a 
parameter  template,  an  argument's  target  does  not  require 
SENVRTS,  regardless  of  whether  or  not  Nproc  has  SPROCESSRTS. 
$LNS  and  $LNSRESTRICT  are  always  allowed. 

Signals: 

See  SMAKELNS  and  SLNSCALL 
Result: 

Value  returned  by  callee 


vSSUSPEND  ( Value,  SIndex,  Smemrts  ) 

Parame-tfiiis: 

i Value  - Integer 

; j SIndex  - Simple  index,  SENVRTS,  or  0 

i Smemrts-  Legitimate  stack  memorj'- address,  or  0 

I Effect: 

Causes  return  of  control  to  current  LNS's  caller  with  result 
Value.  If  Value  is  negative.  Value  is  signalled  as  well  in  the 
caller's  environment.  If  the  caller  specified  a Return  slot  and 
SIndex  is  non-zero  (and  the  return  slot  has  not  otherwise  had  a 
j • capability  stored  into  it),  the  capability  denoted  by  SIndex  is 
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returned  to  th.at  slot  in  the  caller's  LNS  with  rights  restricted  by 
the  contents  of  Smemris  (if  Smemrts  is  not  zero)  and  with 
SDELETERTS  added. 

If  the  current  LNS  has  no  caller,  the  current  PROCESS  will  be 
stopped.  Attempts  to  restart  it  will  be  unsuccessful.  See  sections 
3. 1.7.4  and  G.3. 

Result: 

Current  value  of  RO.  Control  returns  to  caller  (unless  a 
signal  occurs).  Control  only  continues  normally  after  a $SUSPEND 
if  the  current  LNS  is  subsequently  $LNSCALLed  again. 


SRETURN  { Value,  SIndex,  Smemrts  ) 

Parameters: 

Value  - Integer 

SIndex  - Simple  index,  SENVRTS,  or  0 

Smemrts  - Legitimate  stach  memory  address,  or  0 
Effect: 

Causes  return  of  control  to  current  LNS's  caller  with  result 
Value.  If  Value  is  negative.  Value  is  signalled  in  the  caller's 
environment.  If  the  caller  specified  a Return  slot  and  SIndex  is 
non-zero  (and  the  return  slot  has  not  otherwise  had  a capability 
$PUTCAPAd  into  it),  the  capability  denoted  by  SIndex  is  returned 
to  that  slot  in  the  caller's  LNS  vrith  rights  restricted  by  the 
contents  of  Smemrts  (if  Smemrts  is  nonzero),  and  wnth 
SDELETERTS  added. 

If  the  current  LNS  has  no  caller,  the  current  PROCESS  \.vill  be 
stopped.  Attempts  to  restart  it  will  be  unsuccessful. 

Result: 

Current  value  of  RO.  Control  returns  to  caller  (unless  a 
signal  occurs).  Any  attempt  to  resume  execution  via  SLNSCALL 
will  result  in  a signal  SKySREUSE^^, 


Actually,  SHETURU  Is  not  a separata  K-call;  It  Is  a macro  which  expands  Int.^  a SSUSPEMD, 
followed  by  a loop  containing  a SSL'SPEND  which  signals  SHySRE'JSE.  There  are  several 
reasons  for  renaming  the  old  SRETU.RN  K-call  to  be  SSUSPETJO  and  creating  this  macro. 
They  deal  primarily  with  concepts  of  program  clarity  and  erne  of  undor.r-.nd.r.gi  it  Is  (or 
should  be)  perfectly  obvious  to  both  programmer  and  reader  of  code  that  a procedure  Is 
Intended  to  resume  after  a $SUSPEND  but  not  after  a SRETURIJ.  It  also  means  that  an  L'.’S 
•which  was  not  Intended  to  be  re-used  will  not  be  inadvertently  re-used  because  someone 
forgot  to  set  the  re-use  flag. 
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I 2.2. 7. 5 Protected  Subsystems 

' 3TYPECALL  ( Dindex,  SPath,  TPath,  <arguments>  ) 


Parameters: 

Dindex  - Simple  indeX;  empty  or  0 
SPath  - Path,  defined 

TPath  - Path  beginning  in  the  C-list  of  the  TYPE  object 
whose  name  is  the  type  of  SPath,  PROCEDURE 
object  reference,  $CALLRTS 


- Specifications  for  <arguments>  are  exactly  as  for 
SMAKELNS. 

Efrect; 

If  we  let  be  the  TYPE  representative  for  the 

capability  (object  or  template)  targeted  by  SPath,  then  the  effect  is 
(roughly)  equivalent  to: 


8GETCAPA  <*,TYPsp2^h^; 

SCALL  ( Dindex,  SPATHC*, TPath) , <arguments>); 


that  is,  the  Kernel  SCALLs  the  procedure  in  the  type  object 
without  the  caller  getting  a capability  itself  for  the  procedure. 
See  section  2.2.6  and  Figure  5. 

Signals; 

See  SCALL 
Besillli 

Value  returned  by  callee 
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Appendix  K:  K-call  macro  summary 

This  appendix  summarizes  the  Kernel  calls  and  their  parameters  and 
provides  a quick  reference  both  to  the  calls  and  to  their  descriptions  in  the 
manual.  The  flags  in  the  left  column  are  those  which  appear  with  the 
Kernel  call  in  its  description  in  the  manual,  and  are  explained  in  section 
1.1.4. 


SAPPENDCAPA  ( DPath,  SIndex,  Smemrts  ) 2-25 

$APPENDDATA  ( DPath,  MemRn,  Count ) 2-2 1 

P $ ATTACHPOLICY  ( Nprcs,  Npol,  SBase  ) 3-15 

$BASECALL  ( Dindex,  SPath,  arguments  ) 3-10 

$CALL  ( Dindex,  Sproc,  arguments  ) 2-53 

SCHANGETYPESPECS  (Dindex,  SMemRlO)  2-41 

$CLENGTH  ( SPath  ) 2-17 

$COMPAPE  ( SPath,  SIndex  ) 2-18 

SCONNECT  ( Portl,  Outchan,  Port2,  Inchan,  Connid  ) 6-9 

P SCONTROL  ( Nprcs,  Code  ) 3-12 

$COPY  ( Dindex,  SIndex,  arguments  ) 2-44 

$COPY  ( Dindex,  SPage,  Ncps  ) 4-5 

SCPSLOAD  ( Dins,  Pairlist ) 4-6 

$CREATE  (Dindex,  SType,  SMemRlO)  2-40 

SCREATE  ( Dindex,  SIndex,  arguments  ) 2-43 

$CREATE  ( Dindex,  SPrcs,  SLns  ) 3-2 

SCREATE  ( Dindex,  SPrcs,  args,  SProc  ) 3-3 

SCREATE  (Dindex,  SPol,  Data  ) 3-14 

SCREATE  (Dindex,  SPort,  NMsgSlots,  NDummy,  NOutchan,  NResources) 

6-8 

SCREATE  (Dindex,  SSem,  Count)  7-1 

SCREATE  (Dindex,  SPage,  Flags)  H- 1 

SCREATE  (Dindex,  SPort,  NMsgSlots,  NDummy,  NOutchan,  NResources)  H- 

2 

SCREATE  (Dindex,  SSem,  Count)  H-3 

SCREATE  ( Dindex,  SPrcs,  SLns  ) H-3 

SCREATE  ( Dindex,  SPrcs,  args,  SProc  ) H-4 

SCREATE  (Dindex,  SProc)  H-5 

SCREATE  (Dindex,  SPol,  Data  ) H-6 

SDELETE  ( DPath  ) 2-25 

SDELETEMSGCAPA  (Port,  MsgSlot)  6-33 

» SDESTROY  ( DPath  ) 2-44 
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$DISCONNECT  ( Port,  Outchan  ) 6-11 

$DLENGTH  ( SPath  ) 2-17 

* $ERA5E  ( DIndex  ) 2-47 

* $FREEZE  ( DIndex,  Slndex,  arguments  ) 2-45 

SGETCAPA  ( DIndex,  SPath  ) 2-24 

X SGETCLOCK  ( SMemW4  ) 2-29 

$GETDATA  ( MemWn,  SPath,  Disp,  Count ) 2-19 

$GETGMT  (MemW4)  2-27 

$GETICB  ( SMemWn,  SPath,  Code  ) 2-63 

$GETLCB  ( SMemWn,  SPath,  Coda  ) 2-64 

SGETMSGCAPA  (Port,  MsgSlot,  DIndex)  6-33 

P SGETPCB  ( SMemWn,  SPath,  Code  ) 3-9 

P $GETPOLICY  ( SMemWie,  Npol ) 3-15 

SGETPROCESSID  ( ) 3-9 

SGETSTACK  ( SMemWn,  SLns,  MemLns,  Count ) 2-65 

SGETUPTIME  (MemW4)  2-28 

$GMTTOLQCAL  (MemWn,  Count)  2-28 

$GNAMETOGMT  (MemW4,MemR4)  2-27 

P $INFPOLICY(  ) 3-17 

SINTERCHANGE  ( DPath,  DIndex,  Smemrts  ) _ 2-26 

$KALLIMDIRECT  (SMemRn)  2-29 

* SLNSCALL  ( DIndex,  Nlns  ) 2-52 

SLNSLEfJGTH  ( ) 2-17 

* $MAKEALIAS  ( DIndex,  Slndex  ) 2-46 

$MAKEDATA  ( DPath,  MemRn,  Count,  Smemrts  ) 2-20 

* $MAKELNS  ( DIndex,  Nproc,  arguments  ) 2-49 

SMAICEMSG  ( Port,  Buflen,  Stkdep  ) 6-12 

$MAKE?AGE  ( DPath  ) 4-6 

$MAKETEMPLATE  ( DPath,  Slndex,  Smemrts  ) 2-42 

$MAKETEMPLATE  ( DPath,  Slndex,  Smemrts  ) H-7 

SMAKEUNIVERSAL  ( DPath  ) 2-22 

SMERGE  ( DIndex,  STempl,  SPath  ) 2-48 

SNCONNECT  (Portl,  Outchan,  Port2,  Inchan,  Ccnnid,  Disconnopt)  6-10 
SOBJIiVFO  ( SMemW'l 6,  SPath  ) 2-18 

$P  (DIndex)  7-2 

$PASS  ( DPath,  Slndex,  SMemrts  ) 2-22 

SPASSAPPEND  ( DPath,  Slndex,  Smemrts  ) 2-24 


Also  knov/n,  for  historical  reasons,  as  SLOAD. 
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• SPASSMSGCAPA  (Port,  MsgSlot,  SIndex,  Memrts)  6-35 

SPCONDITIONAL  (Dlndex)  7-4 

SPROCESSTIME  ( SMemWE  ) 3-11 

SPUTCAPA  ( DPath,  Slndex,  Smemrts  ) 2-23 

$PUTDATA  ( DPath,  MemRn,  Disp,  Count ) 2-19 

$PUTMSGCAPA  (Port,  MsgSlot,  Slndex,  Memrts)  6-32 

SPUTSTACK  ( DLns,  MemLns,  SMemRn,  Count ) 2-65 

$READMSG  ( Port,  MsgSlot,  Pos,  Len,  MemWn  ) 6-13 

» $REALLY  ( Dlndex,  Slndex  ) 2-46 

X SRECEIVEMSG  ( Port,  Ctype,  Class,  Mask,  SMemW6  ) 6-26 

SREPLYMSG  ( Port,  MsgSlot,  Type  ) 6-20 

$REQUEUEMSG  (Port,  MsgSlot,  Type,  Channel,  Messid,  Connid,  Replybit) 

6-29 

SRESCHEDULE  ( Tim  ) 3-13 

« $RESTRICT  ( DPath,  Smemrts  ) 2-26 

SRETURN  ( Value,  Slndex,  Smemrts  ) 2-54 

* SREVOKE  ( Dlndex  ) 2-46 

SRPSLOAD  ( Nlns,  Nrps,  Ncps  ) 4-7 

$RRL0AD  ( Nrps,  Ncps  ) 4-8 

$RRUNLOAD  ( Nrps  ) 4-8 

SRSVPMSG  ( Port,  MsgSlot,  Type,  Outchan,  Messid,  Inchan,  Replym  ) 6-16 
$SENDMSG  ( Port,  MsgSlot,  Type,  Outchan  ) 6-19 

$SETCHKRIGHTS  ( DPath,  SMemrts  ) 2-43 

SSETDLENGTH  ( DPath,  Count)  2-2 1 

$SETICB  ( DPath,  SMemRn,  Code  ) 2-63 

$SETLCB  ( DPath,  SMemRn,  Code  ) 2-64 

P $SETPCB  ( DPath,  SMemRn,  Code  ) 3-10 

P SSETPOLICY  ( Dlndex,  Slndex,  SMemRlS  ) 3-16 

P SSTART  ( Slndex  ) 3-11 

P $ST0P  ( Nprcs,  Code  ) 3-12 

$ SUSPEND  ( Value,  Slndex,  Smemrts  ) 2-53 

SSWITCH  (DPath,  Dlndex)  2-45 

STAKE  ( Dlndex,  SPath  ) 2-23 

» STAKEMSGCAPA  (Port,  MsgSlot,  Dlndex)  6-34 

STIMEDRECEIVE  (Port,  Timeout,  Typemask,  Chanmask,  Messid,  SMemW6) 

6-22 

STRUNCATEMSG  (Port,  MsgSlot,  Length)  6-3 1 


Also  known,  for  historical  reasons,  as  SSTORE. 
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$T\TECALL  ( Dinde.v,  SPath,  TPath,  arguments  ) 2-55 

‘ $T\TERETR1EVE  ( DIndex,  SIndex  ) 2-47 

$ UPDATE  ( SPath  ) 5-1 

* $UPDATE?J  (SPath, Depth)  5-2 

$V  (DIndex)  7-3 

$VACATE  ( DPath  ) 2-25 

$VALL  (DIndex)  7-3 

P $WHATPOLIcy(SMemW16,Npol)  3-16 

* SWORKSET  ( Nlns,  Size  ) 4-9 

SWRITEMSG  ( Port,  MsgSlot,  Pos,  Len,  MemRn  ) 6-14 
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Active  GST  5-1 
Active  region  of  suck  2-12 
Address,  trap,  user  2-57 
Allas  2-36 

Allas,  Creation  of  2-46 

Amplification,  rights  2-31 

Amplification,  rights  which  cannot  be  obtained 

2- 34 

APPENDCAPA,  K-call  2-25 
APPENDCAPARTS,  right  defined  2-6,  A-1 
APPENDDATA,  K-call  2-21 
APPENDDATARTS,  right  defined  2-6,  A-1 
APPENDDATARTS,  right  used/requlred  A- 13 
ARGMIN,  ICB/LCB  field  2-62,  F-6 
ARPAnet  interface  3-20 
ASLI  link  8-18 

Asynchronous  Line  Interface  (ASLI)  8-18 
ATTACHPOLICY,  K-call  3-4,  3-15 
ATTACHPOLRTS,  right  defined  A- 10,  A-1 1 
ATTACH  POLRTS,  right  used/requlred  3-16 
Auxiliary  rights  2-8 

Backdoor  K-calls  J-1 

Base,  process  3-3 

BASECALL,  K-call  3-10 

BASERTS,  right  defined  A-1 1 

BASERTS,  right  used/requlred  3-16,  A-11 

BPTPC  (BPT  trap  PC)  2-57 

BPTPC,  ICB/LCB  field  F-6 

Buffer  size,  device  8-3 

Buffer,  Indirect  8-3,  8-4 

C-llst  2-1,  2-2 

C-llst  rights  2-5 

C-llsi,  maximum  size  A-6 

Cacheablo  page  4-5 

CACHERTS,  right  defined  4-5,  A-12 

CACHERTS,  right  used/requlred  4-6,  4-7 

Call  mechanism  2-2 

CALL,  K-call  2-63 

CALL,  stack  format  1-3 

CALLRTS,  right  defined  A-9 

CALLRTS,  right  used/requlred  2-63,  2-65,  2-60, 

3- 10,  A-2 
Capabilities  2-1 
Capabilities,  Inherited  2-30 
Capability  part.  In  message  6-1 
Capability  rights  2-4 
Capability,  confined  2-36 
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CBALLHEGS,  ICB/LCB  field  F-10 
CBARGINF,  ICB/LCB  field  F-10 
CBARGS,  ICB/LCB  field  2-62,  F-6 
CBCALLINF,  ICB/LCB  field  F-10 
CBCPSLIMIT,  ICB/LCB  field  4-3,  4-4,  4-9,  F-6 
CBDATA,  ICB/LCB  field  F-10 
CBDEBUG,  ICB/LCB  field  F-10 
CBERRORTRAPS,  ICB/LCB  field  F-10 
CBICPSLENGTH,  ICB/LCB  field  4-4,  F-6 
CBINITCPS,  ICB/LCB  field  4-4 
CBINITCPSBLOCK,  ICB/LCB  field  F-10 
CBINITCPS[l],  ICB/LCB  field  F-6 
CBINSTRAPS,  ICB/LCB  field  F-10 

CBLCBINF,  ICB/LCB  field  F-10 
CBLNSDATA,  ICB/LCB  field  2-62 
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CBLNSET,  ICB/LCB  field  F-10 
CBLNSGET,  ICB/LCB  field  F-1 1 
CBPC,  ICB/LCB  field  F-7 
CBPCTRAP5,  ICB/LCB  field  F-1 1 
CBPROCDATA,  ICB/LCB  field  2-62 
CBPROCDATABLOCK,  ICB/LCB  field  F-1 1 
CBPROCDATA[l],  ICB/LCB  field  F-7 
C3PROCSET,  ICB/LCB  field  F-1  1 
CBPS,  ICB/LCB  field  2-61,  4-6,  F-7 
CBPSPC,  ICB/LCB  field  F-1 1 
CBREGl,  ICB/LCB  field  F-7 
CEREG2,  ICB/LCB  field  F-7 
CBREG3,  ICB/LCB  field  F-7 
CBREG4,  ICB/LCB  field  F-7 
CBREG5,  ICB/LCB  field  F-7 
CBREGS,  ICB/LCB  field  F-1 1 
CBSAVEAREA,  ICB/LCB  field  F-1 1 
CBSAVEREG,  ICB/LCB  field  F-7 
CBSAVEREGS,  ICB/LCB  field  F-1 1 
CBSAVEVAL,  ICB/LCB  field  F-7 
CBSP,  ICB/LCB  field  2-62,  F-7 
CBSTACKGROW,  ICB/LCB  field  2-62,  F-7 
CBSTKOWN,  ICB/LCB  field  F-7 
CBTRAPS,  ICB/LCB  field  F-1 1 
CBUSERTRAPS,  ICB/LCB  field  F-1 1 
CBVREG,  ICB/LCB  field  2-61,  F-7 
CHANGETYPERTS,  right  defined  A-7 
CHANGETYPESPECS,  K-call  2-41 
Check  rights  field  2-31,  2-43,  2-48 
Check  rights,  default  2-31 
CLENGTH,  K-call  2-17 
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Clock,  Line  Frequency  S-8 
COMPARE  K-call,  format  C-1 
COMPARE,  K-call  2-18 
Confined  capability  2-36 
Confined  LNS  2-35 
Confinement  2-35 
CONNECT,  K-call  6-4,  6-9,  8-1 
Connection  ID,  port  6-4 
Connection,  port  6-3 

CONNECTRTS,  right  defined  6-5,  A-4,  A-5,  A- 14 
CONNECTRTS,  right  used/requIred  6-9,  6-11 
Context  block.  Initial  2-55 
Context  block,  local  2-55 
Context  blocks,  examining  2-63,  2-64 
Context  blocks,  setting  2-63,  2-64 
Control  Interrupts  2-60 
CONTROL  on  blocked  process  7-3,  7-6 
CONTROL,  K-call  2-60,  3-12 
Control,  Punting  2-60 
COPY,  K-call  2-44,  4-5 
COPY,  of  PAGE  object  4-6 
Copying  a PAGE  object  4-5 
COPYRTS,  right  defined  4-6,  A-1 
COPYRTS,  right  used/requlred  2-44,  4-5,  A-9,  A- 
12,  A- 13 

CPS,  current  page  set  4-1 

CPSLOAD,  explained  4-2 

CPSLOAD,  K-call  4-6 

CPSLOAD,  stack  format  1-3 

CPSRTS,  right  defined  4-5,  A-6,  A- 12 

CP5RTS,  right  used/required  4-4,  4-6,  4-7,  4-9, 

! A-12 

CPUMASK,  ICB/LCB  field  2-60,  F-7 
CREATE,  K-call  2-40,  2-43,  3-2,  3-3,  3-14,  6-8, 
7-1,  H-1,  H-2,  H-3,  H-4,  H-5,  H-6 
CREATE. REQ[N81  1HY97]  2-39 
CREATEBLOCK,  $CREATE  parameter  block  field  A- 
8 

CreateCapalnIt,  SCREATE  parameter  block  field 
A-8 

CreateCapaMax,  $CREATE  parameter  block  field 
A-8 

CreateDatalnIt,  $CREATE  parameter  block  field  A- 
8 

CreateDalaMax,  SCREATE  parameter  block  field 
A-8 

CreatePNAME,  SCREATE  parameter  block  field  A- 
8 


CreateRetrleveFlag,  SCREATE  parameter  block 
field  A-8 

CHEATERTS,  right  defined  A-1 
CREATERTS,  right  used/requlred  2-37,  2-40, 

2-43,  3-2,  3-3,  3-14,  6-8,  7-1,  A- 
7,  A-9,  A-12,  A-13,  A-14,  A-16,  H- 
2,  H-3,  H-4,  H-6 

CreateTempFlag,  SCREATE  parameter  block  field 
A-8 

Creation  of  Allas  2-46 

Creation  of  DATA  object  2-20 

Creation  of  LNS  object  2-49 

Creation  of  Message  6-12 

Creation  of  NULL  object  H-5 

Creation  of  PAGE  object  4-6,  H-1 

Creation  of  POLICY  object  3-14,  H-6 

Creation  of  PORT  object  6-8,  H-2 

Creation  of  PROCEDURE  object  H-5 

Creation  of  PROCESS  object  3-2,  3-3,  H-3,  H-4 

Creation  of  SEMAPHORE  object  7-1,  H-3 

Creation  of  Template  2-42,  H-7 

Creation  of  TYPE  object  2-40,  H-6 

Creation  of  UNIVERSAL  object  2-22 

CTLCODE,  ICB/LCB  field  2-60 

CTLCODE,  stack  page  location  F-5 

CTLDEBUG,  JCB/LCB  field  F-1  1 

CTLMASK  (Control  mask),  ICB/LCB  field  2-60 

CTLMASK,  default  F-5 

CTLMASK,  ICB/LCB  field  F-7 

CTLPC  (Control  PC),  ICB/LCB  field  2-60 

CTLPC  (Control  trap  PC)  2-56 

CTLPC,  ICB/LCB  field  F-7 

CTLRTS,  right  defined  A-1 1 

CTLRTS,  right  used/requlred  3-12 

CTLTRAP,  ICB/LCB  field  F-1  1 

Current  page  set,  CPS  4-1 

DATA  A-13 

Data  area.  Kernel  2-13 

DATA  object.  Creation  of  2-20 

Data  part  2-2 

Data  pari  rights  2-6 

Data-part,  maximum  size  A-6 

Date  2-27,  D-1 

Debugging  procedure  2-60 

DEBUGINDEX,  ICB/LCB  field  2-60,  F-7 

DEBUGMASX,  ICB/LCB  field  F-7 

DECtape  8-13 

Default  SCTLMASK  F-5 
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DELETE,  K-call  2-25 
DELETEMSGCAPA,  K-call  6-33 
DELETERTS,  right  doflned  2-6,  A-1 
DELETERTS,  right  used/requtred  3-34 
DESTROY,  K-call  2-44 
DESYNCH  on  blocked  process  7-3,  7-5 
DEVICE  A-14 
Device,  buffer  size  8-3 
Device,  operation  code  8-2 
DIDENTIFY,  I/O  opcode  8-6 
DIndex,  K-call  parameter  symbol  2-16 
DISCONNECT,  K-call  0-4,  0-11, ■ 8-1 
Disk,  fixed  head  8-17 
Disk,  moving  head  8-15 
DLENGTH,  K-call  2-17 
DPath,  K-call  parameter  symbol  2-16 
DSTATUS,  I/O  opcode  8-7,  8-8,  8-9,  8-11,  8-14, 
8-16,  8-20,  8-22 

Empty  slot  2-34 

EMTPC  (EMT  trap  PC)  2-67 

EMTPC,  ICB/LCB  field  F-7 

Environment  2-2 

ENVRTS,  right  defined  2-6,  A-1 

ENVRTS,  right  used/requlred  2-34,  2-35,  2-53 

ENVRTS,  special  case  In  LNS  Incarnation  2-63 

ERASE,  K-call  2-47 

ERRCOD.REQ[N81 1HY97]  F-6 

ERRCODE,  stack  page  location  F-5 

Error  code  $HyErrBADRTI  F-6 

Error  code  $HyErrBADSP  F-6 

Error  code  $HyErrCPU  F-0 

Error  code  SHyErrILL  F-6 

Error  code  ^HyErrNXM  F-6 

Error  coda  $HyErrSPRANDOM  F-0 

Error  flag  2-58 

ERRPC  (error  trap  PC)  2-58 

ERRPC,  ICB/LCB  field  2-58,  F-7 

ERRSP,  stack  page  location  F-6 

ERRTYPE,  I/O  reply  type  8-5,  8-6 

ESL  (KWl  IP)  8-23 

Event  frame  (KIAM  IP)  8-23 

Event  Signal  Locations  (KWl  IP)  8*23 

Executing  procedure  2-2 

Fixed  head  disk  8-17 
Frame,  event  (KWllP)  8-23 
FREEZE,  K-call  2-45 


FREEZEFLAG  2-34,  2-47,  2-48,  2-60,  2-51,  4-6, 
4-7,  A-1,  A-10,  A-12 
FREEZEFLAG,  right  defined  A-4 

Generic  rights  2-8 
GETCAPA,  K-call  2-24 
GETCAPARTS,  right  defined  2-5,  A-1 

11 

GETCBRTS,  right  used/required  2-61,  2-66, 

2-63,  2-64,  3-9,  A-10 
GETCLOCK  K-call  Return  Formal  E-1 
GETCLOCK,  K-call  2-29 
GETDATA,  K-call  2-19 
GETDATARTS,  right  defined  2-6,  A-1 
GETDATARTS,  right  used/requlred  A- 13 
GETGMT,  K-call  2-27 
GETICB,  K-call  2-63 
GETLCB,  K-call  2-64 

GETPCB,  K-call  3-9 
GETPOLICY  K-call,  format  G-3 
GETPOLICY,  explained  3-7 
GETPOLICY,  K-call  3-15 
GETFOLICYRTS,  right  defined  A-10 
GETPOLICYRTS,  right  used/requlred  3-16 
GETPROCESSID,  K-call  3-9 
GETSTACK,  K-call  2-65 
GETSTACKRTS,  right  defined  A-10 
GETSTACKRTS,  right  used/requlred  2-51,  2-65, 
A-10 

GETUPTIME,  K-call  2-28 
GMT,  SGMTTOLOCAL  result  field  D-1 
GMT.REQ[NS1  IHY97]  D-1 
GMTBLOCK,  $GMTT0L0CAL  result  field  D-2 
GMTDATEO,  $GMTTOLOCAL  result  field  D-2 
GMTDAY,  SGMTTOLOCAL  result  field  D-2 
GMTDECDATE,  SGMTTOLOCAL  result  field  D-2 
GMTDST,  SGMTTOLOCAL  result  field  D-2 
GMTHR,  $GMT70L0CAL  result  field  D-2 
GMTJULIAN,  $GMTTOLOCAL  result  field  D-2 
GMTLEAP,  SGMTTOLOCAL  result  field  D-2 
GMTMIN,  SGMTTOLOCAL  result  field  D-2 
GMTMON,  SGMTTOLOCAL  result  field  D-2 
GMTOFFSET,  SGMTTOLOCAL  result  field  D-2 
GMTSEC,  SGMTTOLOCAL  result  field  D-2 
GMTTOL<XAL  K-call  return  format  D-1 
GMTTOLOCAL,  K-call  2-28 
GMTWKDAY,  'SGMTTOLOCAL  result  field  D-2 
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GMTYEAR,  $GMTTOLOCAL  result  field  D-2 
GNAMETOGMT,  K-call  2-27 
GPERROR,  $GETPOLICY  field  G-4 
GPNSLICES,  $GETPOL!CY  field  G-3 
GPPOLID,  $GETPOLICY  field  G-3 
GPRCVCODE,  SGETPOLICY  field  G-3 
GPSTR,  SGETPOLICY  field  G-3 
GPTJMER,  $GETPOLlCY  field  G-3 
GPTIMREQ,  SGETPOUCY  field  G-4 
GPWSLIMIT,  SGETPOLICY  field  G-4 
GPWSREQ,  $GETP0L1CY  field  G-4 
GPWSSlZE,  $GETP0L1CY  field  G-4 
GST,  active  5-1 
GST,  passive  5-1 

High-resolutlon  clock  8-22 
Hydra  User  Area  1-2 
HyErrBADRTl,  error  code  F-6 
HyErrBADSP,  error  code  F-6 
HyErrCPU,  error  code  F-6 
HyErrlLL,  error  code  F-6 
HyErrNXM,  error  code  F-6 
HyErrSPRANDOM,  error  code  F-6 
HyPSCC,  Virtual  PS  field  2-57 
HyPSCONFlNED,  Virtual  PS  field  2-57 
HyPSERH  2-58 

HyPSERR,  Virtual  PS  field  2-57 
HyPSPRIOniTY,  Virtual  PS  field  2-57 
HyPSREUSE,  Virtual  PS  field  2-57 
HyPSSPACE,  Virtual  PS  field  2-57 
HyPSTT,  Virtual  PS  field  2-57 
HyPSword,  Virtual  PS  structure  2-68 
HySALlAS,  signal  2-45,  F-2 
HySALREADYCONNECTED,  signal  6-10,  F-4 
HySBADCOUNT,  signal  7-1,  F-3 
HySBADTYPESPEC,  signal  F-2 
HySBUFFBOUNDS,  signal  6-14,  6-15,  6-31,  F-3 
HySBUFFLENGTH,  signal  6-13,  F-3 
HySCANTCONFINE,  signal  2-52,  F-2 
HySCANTLOCK,  signal  2-45,  2-62,  3-2,  F-1,  H-4 
HySCBOUND,  signal  2-44,  F-1 
HySCBPS,  signal  2-63,  F-2 
HySCBSP,  signal  2-64,  F-2 
HySCHECKRTS,  signal  2-48,  F-2 
HySCODE,  signal  2-63,  2-64,  3-9,  3-10,  F-2 
HySCONNECT,  signal  6-10,  F-4 
HySCONTROL,  signal  2-52,  2-60,  F-2 
HySCPSBOUMD,  signal  4-6,  4-7,  4-8,  4-9,  F-3 


HySCREATEMSG,  signal  6-12,  F-4 
HySDBOUND,  signal  2-20,  2-21,  2-44,  F-1 
HySDlSCONMSG,  signal  6-19,  F-3 
HySDISCONNECT,  signal  6-12,  F-4 
HySDKIND,  signal  F-1 
HySDOWN,  signal  6-10,  F-4 
HySDRTS,  signal  F-1 
HySDTYPE,  signal  F-1 
HySEXCLUSIVE,  signal  6-10,  F-4 
HySFARG,  signal  2-52,  2-62,  F-2 
HySFREEZE,  signal  2-45,  F-2 
HySGETMSGCAPA,  signal  6-34,  F-4 
HySGMT,  signal  2-28,  F-2 
HySGUAR,  signal  3-12,  3-16,  F-2 
HySlCHANRANGE,  signal  6-10,  6-19,  6-30,  F-3 
HySlGBIT,  signal  F-1 
HySIPSMAX,  signal  4-9 
HySKiNDP,  signal  F-1 
KySLNSMEM,  signal  2-65,  F-2 
HySLPS,  signal  2-64 
HySMAKELHS,  signal  2-52,  F-2 
HySMARG,  signal  2-62,  F-2 
HySMEM,  signal  F-1 
HySMERGE,  signal  2-48,  F-2 
HySMSGRTSADDR,  signal  6-32,  6-35,  F-4 
KySMSGSLOTFREE,  signal  6-14,  6-16,  6-19, 
6-21,  6-30,  6-31,  6-32,  6-34, 
6-35,  F-3 

HySMSGSLOTRANGE,  signal  6-14,  6-15,  6-19, 
6-21,  6-30,  6-31,  6-32,  6-34, 
6-35,  F-3 

HySNOALIAS,  signal  2-46,  F-1 
HySNOCLIST,  signal  F-2 
HySNOCORE,  signal  F-2 

HySNOFREEWlSGSLOT,  signal  6-13,  6-25,  6-28, 
F-3 

HySNOFREEOCHAN,  signal  6-10,  F-4 
HySN'OKCALL,  signal  F-1 
HySNOLNS,  signal  3-12,  F-2 
HySNOMSGCAPA,  signal  6-34,  F-4 
HySNOPOLBOX,  signal  F-2 
HySN'OPOLICY,  signal  3-12,  F-2 
HySNOSTACK,  signal  2-52,  2-62,  F-2 
HySXOTHULL,  signal  6-34,  F-4 
HySN'OTUNIOUE,  signal  2-45,  2-47,  F-2 
HySOCHANRANGE,  signal  6-10,  6-12,  6-19,  F-3 
HySPACKADR,  signal  6-25,  6-28,  F-3 
HySPAGE,  signal  4-7,  4-9,  F-2 
HySPARITY,  signal  F-2 
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HySPASSMSGCAPA,  signal  6-36,  F-4 
HySPATHPTS,  signal  F-1 
HySPIOERR,  signal  F-4 
HySPORTDESYNCH,  signal  6-26,  6-28,  F-4 
HySPORTERASE,  signal  6-26,  6-28,  F-4 
HySPUTMSGCAPA,  signal  6-32,  F-4 
HySREAD,  signal  6-14,  F-4 
HySRECEIVE,  signal  6-26,  6-27,  F-4 
HySREPLY,  signal  6-21,  F-4 
HySREQUEUE,  signal  6-30,  F-4 
HySRESOURCES,  signal  6-13,  F-4 
HySREUSE,  signal  2-62,  2-54,  3-2,  F-2,  H-4 
HySRPSBOUND,  signal  4-8,  F-3 
HySRSVP,  signal  6-18,  F-4 
HySSEMDESYNCH,  signal  7-3,  7-6,  F-3 
HySSEMERASE,  signal  7-2,  7-4,  F-3 
HySSE.MOVERFLOW,  signal  7-3,  F-3 
HyS.SKIND,  signal  3-1 1,  F-1 
HySSP,  signal  F-1 
HySSRTS,  signal  F-1 
HySSTACKDEPTH,  signal  6-13,  F-3 
HySSTACKOVFL,  signal  6-19,  F-3 
HySSTKFK,  signal  F-2 
HySSTYPE,  signal  2-48,  F-1 
HySTAKEMSGCAPA,  signal  6-34,  F-4 
HySTBND,  signal  F-2 
HySTEXTADH,  signal  6-14,  6-15,  F-3 
HySTIME,  signal  3-14,  F-2 
HySTlMEDRECEIVE,  signal  F-4 
HySTRUNCATEMSG,  signal  6-31,  F-4 
HySTYPBND,  signal  F-2 
HySTYPEBOUND,  signal  2-41 
HySTYPERANGE,  signal  6-19,  6-21,  6-30,  F-3 
HySUNCONNECTED,  signal  6-12,  6-19,  F-3 
HySVALL,  signal  7-2,  F-3 
HySVKSEM,  signal  F-2 
HySWRITE,  signal  6-15,  F-4 
HySWRONGSTATE,  signal  3-10,  3-12,  F-2 


ICB  (Inlllal  context  block)  2-55 
IMP  device  8-20 
Implicit  signals,  summary  F-1 
IMPREAD,  I/O  opcode  8-21 
IMPWRITE,  I/O  opcode  8-21 
INDBUF,  I/O  format  modifier  8-3,  8-4 
Index,  path  2-3 
Index,  simple  2-3 

Indirect  buffer  specification  In  message  8-3,  8-4 
INFPOLICY,  explained  3-7 


B 


INFPOLICY,  K-call  3-17 

Inherited  capabilities  2-30 

Initial  context  block  2-55 

Initial  context  block,  examining  2-63 

Initial  context  block,  setting  2-63 

Initial  page  set,  IPS  4-4 

Initialization  page  4-5 

INITRPS,  ICB/LCB  field  4-4 

INITRPSBLOCK,  ICB/LCB  field  F-1 1 

INITHPS[I],  ICB/LCB  field  F-7 

Input  channel,  port  6-3 

INTERCHANGE,  K-call  2-26 

INTERRUPT  type  linkage.  In  BLISS  2-58 

Interrupts,  control  2-60 

lOOPN,  I/O  opcode  synthesizer  8-4 

lOT,  backdoor  K-call  J-1 

lOTPC  (lOT  trap  PC)  2-58 

lOTPC,  ICB/LCB  field  F-8 

IPS,  Initial  Page  Set  4-4 

Jiffy,  defined  6-23 

K-calls,  backdoor'  J-1 
KALLINDIRECT,  K-call  2-14,  2-29 
KALLINDIRECT,  stack  formats  I-l 
KALSTACKBOUND,  stack  limit  2-62 
KERKAL.RE0[N811HY97]  1-1 
Keri'idl  data  area  2-13 
Kernel  Data  Area  Locations  F-5 
Kernel  signal  2-10 
Kernel  types  2-1 
KILLRTS,  right  defined  2-5,  A- 1 
KI0HAM.REC[N81 1 H Y97]  J- 1 
KKLNAM.REC[N81  1HY97]  F-12,  I-l 
KLASCIIREAD,  I/O  opcode  8-19 
KLBINARYREAD,  I/O  opcode  8-19 
KLINCLEAR,  I/O  opcode  8-19 
KLSETSPEED,  I/O  opcode  8-18 
KLWRITE,  I/O  opcode  8-20 
KMPSDESYNCH,  KMPS  stop  code  G-4 
KMPSNOCORE,  KMPS  stop  code  G-4 
KMPSPGO,  KMPS  stop  code  G-4 
KMPSPOPPED,  KMPS  stop  code  G-4 
KMPSPRCERROR,  KMPS  stop  code  G-4 
KMPSPWAIT,  KMPS  stop  code  G-4 
KMPSREGCPS,  KMPS  stop  code  G-4 
KMPSREOTIM,  KMPS  stop  code  G-4 
KMPSTIMEND,  KMPS  stop  code  G-4 
K\A/1  IP  programmable  clock  8-22 
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KWPIOOKH:,  KWn-P  control  9-18 
KWPlOKHz,  KWn-P  control  9-18 
KWP60HZ,  K W 1 1 -P  control  9-18 
KWPADD,  KWl  1-P  control  8-25 
KWPASL,  KWl  1-P  control  8-25 
KWPASR,  KWl  1-P  control  8-25 
KWPBIC,  KWl  1-P  control  8-25 
KWPBIS,  KV;i  1-P  control  6-25 
KWPCOUNTDOVTN,  KWl  1-P  control  9-18 
KWPCOUNTUP,  KWl  I -P  control  9-18 
KWPCYCLE,  KWl  1-P  control  8-23,  9-18 
KWPDEC,  KWl  1-P  control  8-25 
KWPEVENT,  I/O  opcode  8-23,  8-24 
KWPExlcrnal,  KWl  1-P  control  9-18 
KWPIMC,  KWl  1-P  control  8-25 
KWPMODE,  I/O  opcode  8-23,  8-25,  9-18 
KWPMOV,  KWl  1-P  control  8-25 
KWPPENDING,  I/O  reply  type  8-25 
KWPREPEAT,  KWl  1-P  control  8-23,  9-18 
KWPSTOP,  KWl  1-P  control  8-23,  9-18 
KWPSUB,  KWl  1-P  control  8-25 
KWWAIT,  I/O  opcode  8-8 

LCB  (Local  context  block  2-55 
Legitimate  memory  addresi2-12 
Legitimate  stack  memory  address  2-12 
Length  of  message  6-2 
Line  Frequency  Clock  8-8 
Line  Printer  8-8 
Link,  ASLI  8-18 
LNS  A- 10 

LNS  object.  Creation  of  2-49 
LNS,  $CALL  parameter  function  2-50 
LNS,  confined  2-35 
LNS,  partially  confined  2-35 
LNSCALL,  K-call  2-52 
LNSLENGTH,  K-call  2-17 

LNSRESTRICT,  SCALL  parameter  function  2-50 
LNSRTS,  right  defined  A-9,  A-10 
LNSRTS,  right  used/requtred  2-49,  2-60,  2-62, 
A-2,  A-10 

Local  context  block  2-55 
Local  context  block,  examining  2-64 
Local  context  block,  setting  2-64 
Local  time  2-28 
Locked  object  2-1  I 

LOSTINFOTYPE,  I/O  reply  type  8-6,  8-6 
LPWRITE,  I/O  opcode  8-8 
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MAKEALIAS,  K-call  2-46 

MAKEDATA,  K-call  2-10,  2-20 

MAKELNS,  K-call  2-49 

MAKEMSG,  K-call  6-12 

MAKEMSGRTS,  right  defined  A- 14 

MAKEMSGRTS,  right  used/requtred  6-12 

MAKEPAGE,  K-call  4-6 

MAKETEMPLATE,  K-call  2-42,  H-7 

MAKEUNIVERSAL,  K-call  2-10,  2-22 

Mask,  processor  3-4 

Mem,  K-call  parameter  symbol  2-15 

MEMDATA,  SCALL  parameter  function  2-49 

Memory  address,  legitimate  2-12 

Memory  address,  legitimate  slack  2-12 

MemR  num,  K-call  parameter  symbol  2-15 

MemW  num,  K-call  parameter  symbol  2-15 

MERGE,  K-call  2-48 

Merging  rights  2-33 

Message  length  6-2 

Message  slot,  port  6-3,  6-5 

Message  system  6-1 

Message  type  6-1 

Message,  Creation  of  6-12 

Messages  6-1 

M0DIFYR7S,  right  defined  2-6,  A-1 
MODIFYRTS,  right  used/requtred  2-34,  2-35, 
2-36 

Moving  head  disk  8-15 

N811KY97,  Hydra  user  area  1-2 
NCONNECT,  K-call  6-4,  6-10,  8-1 
New  rights  field  2-31 
NOCOUNT,  1/0  format  modifier  8-4 
NULL  A-9 

NULL  capability  2-34 
NULL  object,  Creation  of  H-5 

Object  2-1 
Objects,  typed  2-1 


OBJRTS,  right  defined  A-1 

OBJRTS,  right  used/requlred  2-44,  2-45,  2-47, 
A-9,  A- 13 

OLDPC,  BLISS  symbol  2-58 
OLDPS,  BLISS  symbol  2-68 
OPDONETYPE,  I/O  reply  type  8-4,  8-6 
Operation  code,  device  8-2 
Output  channel,  port  6-3 
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Owner,  port  6-1 

P,  K-call  7-2 

Page  4-1 

PAGE  A-  1 1 

Page  frame  4-1 

PAGE  object  4- 1 

PAGE  object,  copying  4-6 

PAGE  object.  Creation  of  4-6,  H-1 

Page  set,  current  4-1 

Page  set.  Initial  4-4 

Page  set,  relocation  4-1 

Parameter  templates  2-31 

Partially  confined  LNS  2-35 

PASS,  K-call  2-22 

PASSAPPEND,  K-call  2-24 


Passive  GST  5-1 
PASSMSGCAPA,  K-call  6-35 
Path  Index  2-3 

PATH,  SCALL  parameter  function  2-49 

PATH,  parameter  format  I- 1 

Path,  pretarget  2-3 

Path,  steps  2-3,  2-16 

Path,  target  of  2-3 

Path,  with  confinement  2-36 

PC,  BPT  trap  2-57 

PC,  control  2-53 

PC,  CONTnOE  trap  2-60 

PC,  EMT  trap  2-57 

PC,  error  2-53 

PC,  lOT  trap  2-53 

PC,  signal  2-53 

PC,  trace  trap  2-53 

PCB  (Process  control  block)  3-4 

PCBCPUMASK,  PCB  field  3-4 

PCBCTLCODE,  PCB  field  3-6 

PCBCTLMASK,  PCB  field  3-6 

PCBNSLICES,  PCB  field  3-6 

PCBNUSLICES,  PCB  field  3-6 

PCBPOLID,  PCB  field  3-5 

PCBPHIoniTY,  PCB  field  3-5 

' PCBRCVCODE,  PCB  field  3-6 

PCBSLICESI2E,  PCB  field  3-5 

’ PCBSTATE,  PCB  field  3-6 

PCBTIMER,  PCB  field  3-5 
PCBWSLIMIT,  PCB  field  3-5,  4-3,  4-9 
PCBWSSIEE,  PCB  field  3-6 
PCONDlTiONAL,  K-call  7-4 

• PCONDRTS,  right  defined  A-12 

r* 
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POLICY  A- 10 

POLICY  object.  Creation  of  3-14,  M-6 

P0LKAL.REQ[NB11HY97]  3-3 

POUT  A- 14 

Port  connection  6-3 

PORT  object.  Creation  of  6-8,  H-2 

Port  signals,  summary  F-3 

Port  system  6- 1 

Port,  connection  ID  6-4 

Port,  input  channel  6-3 

Port,  massage  slot  6-3,  6-6 

Port,  output  channel  6-3 

Port,  owner  6-1 

Port,  resource  account  6-3 

Ports  6-1 

Pretarget  2-3 

Printer  8-8 

PROCEDURE  A-9 

PROCEDURE  object.  Creation  of  H-5 
PROCESS  A-1 1 
Process  base  3-3 

Process  control  block:  see  PCB  3-4 
PROCESS  object.  Creation  of  3-2,  3-3,  H-3,  H-4 
Processor  mask  3-4 
PROCESSRTS,  right  defined  A-9 
PROCESSRTS,  right  used/required  2-49,  2-50, 
2-53,  3-2,  3-3,  A- 10,  H-3,  H-4 
PROCESSTIME,  K-call  3-1 1 
Programmable  clock  3-22 
Protected  subsystems  2-31 
PRTS,  right  defined  A-6,  A-12 
PRTS,  right  used/required  7-2,  7-4 
PS,  virtual  2-57 


PUTCAPA,  K-call  2-23 
PUTCAPARTS,  right  defined  2-6,  A-1 
PUTDATA,  K-call  2-19 
PUTDATARTS,  right  defined  2-6,  A-1 
PUTDATARTS,  right  used/required  A- 13 
PUTMSGCAPA,  K-call  6-32 
PUTSTACK,  K-call  2-65 
PUTSTACKRTS,  right  defined  A- 10 
PUTSTACKBTS,  right  used/requlred  2-51,  2-65, 
A-10 


HO,  return  value  of  K-call  2-10 
RO,  return  value  of  signal  2-10 
READMSG,  K-call  6-13 
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READMSGRTS,  right  defined  A- 14 
READMSGRTS,  right  ueed/requlred  6-13 
REALLY,  K-call  2-46 
REALLYRTS,  right  defined  A-1 
REALLYRTS,  right  used/requlred  2-34,  2-35, 
2-36,  2-37,  2-42,  2-46,  2-60, 
2-51,  4-6,  H-7 

RECEIVEMSG,  K-call  6-4,  6-26 
RECEIVEMSG,  timed  6-22 
RECEIVERTS,  right  defined  A-14 
RECEIVERTS,  right  used/requlred  6-26 
Relocation  page  set,  RPS  4-1 
Reply  stack  6-1,  6-2 
Reply  types  8-5 
REPLYMSG,  K-call  6-20 
REPLYMSGRTS,  right  defined  A-14 
REPLYMSGRTS,  right  used/requlred  6-20 
Representation  2-1 
Representation  of  object  2-2 
REOBADBUF,  I/O  reply  type  8-6,  8-25,  9-18 
REQDEVDOWN,  I/O  reply  type  8-5 
REQILLDP,  I/O  reply  type  8-6 
REQILLFMT,  I/O  reply  type  8-6 
REQILLMODE,  I/O  reply  type  8-25,  9-18 
REQILLOP,  I/O  reply  type  8-6 
REQTOOSMALL,  I/O  reply  type  8-6 
REOUEUEMSG,  K-call  6-29 
RESCHEDULE,  cancellation  3-10 
RESCHEDULE,  explained  3-7 
RESCHEDULE,  K-call  3-13 
Resource  account,  port  6-3 
RESTRICT,  K-call  2-26 
Restriction  rights  2-6 

RESTRICTION,  $CALL  parameter  function  2-49 

RETRIEVERTS,  right  defined  A-7 

RETRIEVERTS,  right  used/requlred  2-47 

RETURN,  K-call  2-54 

RETURNINDEX,  ICB/LCB  field  2-62,  F-8 

Reuse  flag  2-61,  4-6 

REVOKE,  K-call  2-46 

RFl  1 (fixed  head  disk)  8-17 

REREAD,  I/O  opcode  8-17 

REWRITE,  I/O  opcode  8-17 

RFWRITECHECK,  I/O  opcode  8-17 

Rights  2-1 

Rights  amplification  2-31 
Rights  field  2-4 
Rights,  auxiliary  2-8 
RIghU,  C-llst  2-6 


Rights,  capability  2-4 

Rights,  checkrlghts  2-31,  2-43,  2-48 

Rights,  data  part  2-6 

Rights,  Generic  2-8 

Rights,  list  of  2-5,  2-6 

Rights,  new  2-31 

Rights,  non-ampllfled  2-34 

Rights,  restriction  2-6 

RPl  1 (moving  head  disk)  8-16 

REREAD,  I/O  opcode  8-15 

RPS,  Relocation  Page  Set  4-1 

RPSEEK,  I/O  opcode  8-15 

RPSLOAD,  explained  4-2 

RPSLOAD,  K-call  4-7 

REWRITE,  I/O  opcode  8-15 

RPWRJTECHECK,  I/O  opcode  8-16 

RRLOAD,  explained  4-2 

RRLOAD,  K-call  4-8 

RRLOAD,  stack  format  J-1 

RRUNLOAD,  K-call  4-8 

RSVPMSG,  K-call  6-16 

RSVPMSGRTS,  right  defined  A-14 

RSVPMSGRTS,  right  used/requlred  6-16,  6- IS 

RTI  Instruction  2-57 

RTS,REQ[N81  'HY97]  A-1,  A-7 

RTSSTR.REQ[IJ81 1HY97]  A-2 

RTT  instruction  2-57 

SAVAREA,  stack  page  location  F-6 
SAVREG,  stack  page  location  F-5 
SAVVAL,  stack  page  location  F-6 
SEMAPHORE  A-12 

SEMAPHORE  object,  Cr-atlon  of  7-1,  H-3 
SENDMSG,  K-call  6-19 
SETCBRTS,  right  dellned  A-9,  A- 10,  A-1 1 
SETCBRTS,  right  used/requlred  2-51,  2-66, 

2-61,  S-63,  2-64,  3-10,  4-6,  4-7, 
4-9,  A-10 

SETCHKRIGHTS,  K-call  2-43 
SETDLENGTH,  K-call  2-21 
SETHOSTDOWN,  I/O  opcode  8-20 
SETHOSTUP,  I/O  opcode  8-20 
SETICD,  K-call  2-63 
SETLCB,  K-call  2-64 
SETPCB,  K-call  3-10 
5ETP0L1CY,  K-call  3-4,  3-16 
SETPOLICYRTS,  right  defined  A-6,  A-10 
SETPOLICYRTS,  right  used/requlred  3-16 
SIGDATA,  stack  location  2-10 
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SIGDATA,  stack  page  location  F-6 
Signal  2-10 

Signal  handler,  example  2-59 
Signals,  Implicit,  summary  F-1 
Signals,  port,  summary  F-3 
Signals,  specific,  summary  F-2 
S1GNLS.REQ[N8UHY97]  2-10,  F-1 
SIGPC  (Signal  trap  PC)  2-58 
SIGPC,  ICB/LCB  field  F-8 
SIGVAL,  stack  page  location  F-6 
Simple  Index  2-3 

Slndex,  K-call  parameter  symbol  2-16 
Size  limit,  of  C-llst  A-6 
Size  limit,  of  data  part  A-6 
Slot  2-2 

Slot,  empty  2-34 

SMem,  K-call  parameter  symbol  2-15 

SMemB  num,  K-call  parameter  symbol  2-lS 

SMemrts,  K-call  parameter  symbol  2-15 

SMemV,!  ,num,  K-call  parameter  symbol  2-15 

SPath,  K-call  parameter  symbol  2-16 

Specific  signals,  summary  F-2 

SPUNDERFLOW,  ICB/LCB  field  2-62,  F-3 

Stack  boundary  values  F-4 

Stack  limit  SKALSTACKBOUND  2-62 

Slack  memory  address,  legitimate  2-12 

Stack  page  2-11 

Stack,  active  region  2-12 

STACKDATA,  SCALL  parameter  function  2-50 

START,  K-call  3-11 

STARTRTS,  right  defined  3-4,  A-1 1 

STARTRTS,  right  used/ required  3-11 

Steps,  In  path  2-3,  2-16 

STKDATA,  SCALL  parameter  function  2-49 

STKOWN,  stack  page  location  F-5 

STKPAG.RF.Q[N81  1HY97]  2-10,  F-5 

STOP,  K-call  3-12 

STOPCD.REQ[N81 1HY97]  G-4 

STOPRTS,  right  defined  A-1 1 

STOPRTS,  right  used/requlred  3-12 

Subsystems,  protected  2-31 

SUSPEND  2-33 

SUSPEND,  K-call  2-53 

SWITCH,  K-call  2-45 

System  up  time  2-28 

TAKE,  K-call  2-23 
TAKEMSGCAPA,  K-call  6-34 
Target,  path  2-3 


TCFIKDBLOCK,  I/O  opcode  8-14 
TCREAD,  I/O  opcode  8-14 
TCREWIND,  I/O  opcode  8-13 
TCSETUNIT,  I/O  opcode  8-13 
TC WRITE,  I/O  opcode  8-14 
Teletype  8-9 
Template  2-37 

Template,  Creation  of  2-42,  H-7 
TemplateFlag  2-34,  A- 7,  A- 9,  A- 1 0,  A- 1 1,  A-  12, 
A- 13,  A- 14,  A- IS 

TEMPLATERTS,  right  defined  A-6,  A-7 
TEMPLATERTS,  right  used/required  2-38,  2-42, 
H-7 

Templates,  parameter  2-31 

Terminal  object  (of  alias)  2-36 

Text  buffer  6-1,  6-2 

Time  2-27,  2-28,  D-1 

Timed  SRECEIVEMSG  6-22 

TIMEDRECEIVE,  K-call  6-4,  6-22 

TRANSFER,  SCALL  parameter  function  2-49 

Trap  address,  user  2-57 

Trap  routines,  requirements  2-53 

TRCPC  (Trace  trap  PC)  2-58 

TRCPC,  ICB/LCB  field  F-8 

Tructure  SHyPSword  2-58 

TRUNCATEMSG,  K-call  6-2,  6-31 

TTEXCP,  1/0  opcode  3-12 

T7INCLEAR,  I/O  opcode  8-12 

TTINRESET,  1/0  opcode  8-12 

TTMODECTL,  I/O  opcode  8-11 

7T0UTRESET,  I/O  opcode  8-12 

TTREAD,  I/O  opcode  8-10 

TTWRI7E,  1/0  opcode  8-10 

Type  1-2 

TYPE  A-7 

TYPE  object.  Creation  of  2-40,  H-6 

Type  TYPE  object  2-37 

Type,  of  message  6-1 

TYPECALL  2-39 

TYPECALL,  K-call  2-55 

Typed  objects  2-1 

TYPERETRIEVE,  K-call  2-47 

TYPES.RE0[N311HY97]  2-42,  A-6,  H-7 

UIO.REQ[NSl  1HY97]  8-6,  8-7 
Unbound  2-34 
Unbound  slot  2-3 

UNBOUNDFLAG,  right  defined  A-6,  A-9 
UNBOUNDFLAG,  right  used/required  2-34 
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UNCFRTS,  right  defined  2-6,  A-1 
UNCfRTS,  right  used/requtred  2-34,  2-36,  2-36, 
2-42,  H-7 

Uninitialized  slot  2-S 
UNIVERSAL  A- 13 

UNIVERSAL  object.  Creation  of  2-22 

UPDATE,  K-call  6-1 

UPDATEN,  K-call  6-2 

User  Area,  Hydra  1-2 

User  trap  address  2-57 

V,  K-call  7-3 
VACATE,  K-call  2-26 
VALL,  K-call  7-3 
VALLRTS,  right  defined  A- 12 
VALLRTS,  right  used/requtred  7-4 
Virtual  PS  2-57 

VREG,  return  value  of  K-call  2-10,  2-16 
VREG,  return  value  of  signal  2-10 
VRTS,  right  defined  A- 12 
VRTS,  right  used/requlred  7-3 

WHATPOLICY,  K-call  3-16 
Working  set  4-3 
WORKSET,  K-call  4-9 
WRITEMSG,  K-call  6-14 
WRITEMSGRTS,  right  defined  A- 14 
WRITEIVISGRTS,  right  used/requlred  6-14 
WRITEPAGERTS  4-5 
WRITEPAGERTS,  right  defined  A-12 
WRITEPAGERTS,  right  used/requlred  4-5,  4-8,  A- 
12 

[N81  1HY97]  CREATE.REQ  2-39 

[N81 1HY97]  ERRCOD.REQ  F-6 

[N81  1HY97]  GMT.REQ  D-1 

[N81  1HY97]  KERKAL.REQ  1-1 

[N81  1HY97]  KIONAM.REQ  J-1 

[N81  1HY97]  KKLNAM.REQ  F-12,  I-l 

[NBl  1HY97]  POLKAL.REO  3-8 

[N81  1HY97]  PS.REQ  2-57 

[N81 1HY97]  RTS.REQ  A-1,  A-7 

[N81  1HY97]  RTSSTR.REO  A-2 

[N81  1HY97]  SIGNLS.REO  2-10,  F-1 

[N81  1HY97]  STKPAG.REQ  2-10,  F-6 

[N81  1HY97]  STOPCD.REQ  G-4 

[N81  1HY97]  TYPES.REQ  2-42,  A-6,  H-7 

[N81  1HY97]  UIO.REQ  8-6,  8-7 


